On Mon, Apr 14, 2008 at 2:29 PM, derwisch < [EMAIL PROTECTED]> wrote:
> > Edward, I am very glad you are sharing your thoughts in this depth. > At the same time I still feel stymied as I just sent in the slides, > where it is basically stated that Leo's data structure basically > reflects > ODM, that Leo is being developed for 10 years and has matured, > is stable, unlikely to undergo big changes etc. Oh my. Just when the old way appeared perfect for you, Leo gets a makeover. A rose by any other name. If you look at the ODM you will see > that there is a distinction between --Ref and --Def elements, and > that some attributes are peculiar to the reference and some to > the definition. You may refer to it as bad style but I was elated > to see this structure mirrored by Leo. Well, there is no standing still. We will have the unified node world, so we must solve your problem, and cleanly. I am afraid I still don't understand the problem. What you present to the user is just another view. It need not contain nodes that you don't want to show. I think it is imperative to distinguish the data as contained in the .xml from the views on the data presented to the user. If necessary, scripts can alway put a subset of data into nodes destined to be seen by the user. So the general idea is: put data that must be contained in multiple views in a node that can then be cloned and added to those views. Very easily done in a script. I guess the overall point is that *you* (and your scripts) are in complete control of what data gets put where. If the .xml mirrors you desires, fine. If not, a simple script should suffice to put the data exactly where you want it in the outline. Note that scripts in @script nodes will be executed when you open a .leo file. Generally speaking, such scripts are dangerous: You must enable @script nodes in the mod_scripting plugin. If you don't like the security implications of @script nodes, you can prototype your scripts with @button nodes, and then you can move your startup scripts into a plugin. Again, the point is that you and your scripts should be able to make the nodes presented to the user look *exactly* how you want them to look, whether or not the nodes are clones or not. The question is, how do I hide the auxiliary nodes from the > user. You have lots of options. You can put them in a chapter. You can put them in a node that is "out of the way" and not usually viewed. If you *really* want to hide data, then you can put the data in a uA in any node you please. A plugin could augment the tree-drawing code so it doesn't show nodes whose headlines start with @hidden. It would take just a few lines of code to do this. You might want to add show-hidden-nodes or hide-hidden-nodes commands :-) > I would really like to preserve the tree view which is > for instance seen in the screenshot of this offer: > http://www.xml4pharma.com/SDTM-ETL/ I see no reason why you couldn't do this. > The other suggestion was outlined by you and Terry in the > parallel thread: to somehow annotate the position during a > traversal of the tree. You call that easy, but then you are a > programmer. I strongly suggest not going in this direction. It's really, really ugly, and it will not be easy to do correctly. I just don't see how I can be wrong about this. In my eyes, you are misusing clones so that they appear differently in different contexts. Yes, the new world would require change to your code at precisely the time you thought it was completely stable. Of course, if you must, you can base your product on the old world. It's always a valid option. But I strongly believe that a little invention on your part will open the door to a much more flexible solution in the long run. Edward --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
