| WikiText textile : define links with workspace path [message #1234283] |
Tue, 21 January 2014 16:02  |
|
Hi,
To create organized documentation and export HTML, I would create links using an implicit name for workspace.
in textile file a link like :
"my title for link":file://<path of html file generated from textile>.
doesn't function.
The lonely link which functions can be currently :
"my title for link":file://<workspace path><path of html file generated from textile>. (if path contains blanks they must be replaced by "%20"
This allows to create an html documentation from textile source which can be accessed by the navigator.
What we could wish :
- Don't fully write the <workspace path> : write the local path (using names if needed) and the extended path will be written in html export
- Be able to launch local edition from the link in textile print preview
- Generate HTML (or others WikiText options for a whole tree (optimizing if it is not a tree but a net)) when launching generate from a top node file. Then the view in navigator gives access to the full cascading documentation generated.
- links to others objects as code and depending or not tasks.
If there are currently full or partial solutions, I would be pleased to know about.
Note about my current use of Eclipse (Kepler sr1)
I have not a long experience of ECLIPSE environment.
I am working on a project which contains 15 000 main pieces of soft (php, js, smarty, css) and 5 versions. More than 50 elementary projects concerning each one generally one to ten pieces of soft with crossed tasks.
There are more than 1000 tasks and near 100 textile documentation texts.
The full soft is 1,300,000 lines of code with 30% original lines.
Best regards
Trebly
Thanks
Trebly
Trebly
|
|
|
|
| Re: WikiText textile : define links with workspace path [message #1235290 is a reply to message #1234337] |
Fri, 24 January 2014 01:41  |
|
Hi,
Your answer is treating of one unique case :
- the capability to define from documents any links defined with relative path. This is common for any HTML generator. The result is the general capabilities from one (any) file (html generated from textile file) which is loaded into a navigator. That's OK.
But this doesn't solve the problem of the management of a documentation of projects managed from an ECLIPSE workspace.
I agree that my example was not the best and could easily create misunderstanding, I give here details about functions that are necessary, in my mind, to manage such documentation.
This is a list of actions on which I spent a lot of time and got errors.
- Generate (or to update) html files corresponding to a net of textile files linked together (a tree or an oriented or not net of documents). This is not in fact the concept of a net of textile files. The net is only in background defined by the links between corresponding html files.
- Any changes of path of folders (move a document, a folder, changes of organization) needed, if textile files with links are implied, must be done completely manually (checks and changes) by modifying the defintion of the links and there are no mean to check the links either than try it.
- It is not possible with the textile editor to open another textile file (linked) for editing it. The user must use either the full workspace tree or the search panel of textile files (what I do).
- The user has no function to get the internal relative path of a file (need to point it into the objects tree, click right, so open properties and copy the content from the panel.. The user must after calculate the relative path from the current path of the current textile file (with five levels hierarchies the error are easy to do).
- I have discovered a rather curious function : If you create a link to a textile file in preview the link opens the file in preview mode. I can understand but it is not useful because this link has no meaning when html is generated. We should need in fact to be able to open the textile source file with the Wikitext editor
If there is currently no available solution, I have some ideas for a way to build a most simple answer to get it
- Be able to use into textile "constants" defined into the full context of a workspace. So for local use (if exported they should be replaced), for preview or for the html links the constants defined should be replaced by their values. Then the list of constants is much more easy to be checked (allows later an automatic check, because the net structure can be easily analysed which is impossible without "id names")
- Some important functions could be called at the beginning of constants strings to get for example "relative path" "full name" "url" of the considered constant value. Then, as the constants are in this context "id names of document objects" their structure become fundamentally independent of the workspace structure.
- We could get a new function (could be valid for whole eclipse) which should allow (by right click on selected text) that the "main menu ob objects " should be displayed for any marked text, this if the current marked text is a valid name of workspace file (absolute or relative). As this marked text can be a definition of a "constant" the user can reach any contextual valid function for any document (or source code etc...) by marking his "id name" and clicking right, this if the "id name" had been well defined. Note : this is the general problem of the identification of objects independently of the structures.
Trebly
Trebly
|
|
|
Powered by
FUDForum. Page generated in 0.03156 seconds
] 
Search
Help
Register
Login
Home
