Thread: [luxor-xul-develop] A new implementation aproach for luxor
Status: Beta
Brought to you by:
vamp201
From: Anakreon <ana...@ya...> - 2004-06-14 17:45:18
Attachments:
sample.tar.gz
|
Hello all. The last 3 days I'm working on a new approach for the implementation of luxor. Currently for each xml element a *Def objects is created and for most elements a *Peer object as well. I was thinking for a way to avoid this, since all this objects require memory and cup. During the design and implementation of the approach, it easy made obvious that more advantages exist then just reduction of cup and memory usage. I'd like to present the design of the approach hopping to get feedback from the luxor team. The design utilizes code generation techniques as well as inheritance and polymorphisms. From a configuration file (see the attachment) the code generation system retrieves information about the supported tags and the properties and css attributes each tag supports. Based on this information an abstract class is generated which handles the tree walking of the XML document, and creates the appropriate components for each tag and reports errors if something goes wrong during the walk. The developer has to extend the class and implement the abstract methods declared in the generated class and override few methods if necessary. One obvious disadvantage of this approach is the fact that differs aloat from the current implementation. For this reason, the advantages should be very significant in order to adopt the new implementation model. I'll try to display the advantages of the approach and I hope in your feedback in order to decide if is worth it to adopt the new design. Let's mention that the existing code base will not be thrown away. The functionality provided by the existing classes should exist in the class which extends the generated class. The existing code will be moved (with some modifications if needed) in the code of the descendant class. Advantages: 1)Less memory used. No intermediate objects are created during the component construction and initialization. No references are kept to the Element object from where the *Def object is created. The GC can free the memory the Element objects occupy. 2)Less cup used. The cup time spent on the *Def and *Peer objects initialization is saved. Also no runtime configuration is needed (in regard to the *Def object). 3)Reduction of code base. I executed the commands displayed bellow and found that 82 *Def classes and 25 *Peer classes exist. The commands are: locate -r .*Def.*.java | rep luxor | wc -l 83 One of the *Def is LuxorDefaultVelocityContext.java and for this reason the sum is 82. locate -r .*Peer.*.java | rep luxor | wc -l 25 Also interfaces like *Resolver are most likely unneeded. More interfaces and classes like the NComponent various Factory classes and the Tag, AbstractComponent, AbstractContainer .. will not be needed any more. So the code base will be reduced by more then 107 classes. This I believe will make it easier to mentain the code base. 4)Easier implementation. If you check the implementation of SwingXulManagerImpl you'll notice that the methods are generally short and simple. Of course not all the functionality required is provided since this is only a proof of concept. The great gain I believe is that a new developer should not have to learn a pretty complex and large object model in order to write code for further luxor improvement. 5)Easier porting to other toolkits. This I count as the greatest benefit. Recently I was looking to the java binding of wxWidgets toolkit (a cross platform toolkit implemented in C++). In order to implement a port to an other toolkit is not needed to duplicate the classes hierarchy which exist for the swing, but simply implement the abstract methods of the generated class. I estimate that the effort is far smaller. 6)Porting for other devices. This is a pure speculation because I have no experience with small devices like cellular phones and the like. However, if such a device can not support an XML parser due to the memory used by the object model it generates, by modifying the template used for the code generation system, a new implementation can be achieved which does not use xml for the gui description, but a less memory demanding way. I recall there are other ways to describe the GUI already (this was a post I red once but can't recall more details). I didn't look at the implementation of those alternative ways of GUI description but I speculate that a Document object was created from that description and fed to luxor. Anyway, if the new approach achieves high reduction of memory usage, we could hope to see luxor on those devices as well. 7)This is not really an advantage, but in order to add a new tag to luxor is needed to modify the config.xml file (this should be easy), regenerate the base class and if needed add some methods in the class which extends the generated one. The effort needed should be equivalent (if not less) to the effort required for the same task in the existing design. 8)Some tasks which could be achieved using Aspect programming or other techniques can now be achieved by modifying the template the code generation system uses. For example, if we wanted a LOG message whenever a new Element is inspected we could modify the template. 9)The code generation system could be used for other tasks, like automatic dtd generation. Well this is all the advantages I could think of. Please have a look at the config.xml file and the SwingXulManager* files. One last comment. The code generation system produces methods like setHeight(JComponent comp, int value) and the like. If the setHeight method should be implemented differently for descendants of JComponent, you could provide a method setHeight(JComponentDecendant comp, int value) and this method will be called if the argument to the setHeight method is a JComponentDecendant due to polymorphisms. I'm looking forward for your comments. Anakreon. |
From: Gerald B. <ge...@va...> - 2004-06-14 19:24:33
|
Hello Anakreon, > The last 3 days I'm working on a new approach for > the implementation of luxor. Lot's of good ideas. I suggest creating a new branch lets say luxor2 in the sourceforge CVS and going ahead with your new approach and clean-up. I've also uploaded your package to the luxor-contrib site so it's easier to download it for further study. See http://sourceforge.net/project/showfiles.php?group_id=64067 (look for the luxor2 package). I'm currently a little stretched so I can't really continue working on Luxor for now. I hope to find more time in about two or three weeks. Once I get started again I plan to look at SwiXml online @ http://www.swixml.org and see if some ideas such as converters and heavy use of reflections may help out Luxor. You might also have a look for some ideas. I also plan to look at Sulu online @ http://sulu.sourceforge.net and see if it makes sense to merge the codebase. You might also have a look for some ideas. To wrap up I urge you to go ahead with lets say a new and fresh luxor2 branch. - Gerald |
From: Anakreon <ana...@ya...> - 2004-06-14 20:32:44
|
> > Lot's of good ideas. I suggest creating a new branch > lets say luxor2 in the sourceforge CVS and going ahead > with your new approach and clean-up. > I'm glad you like the ideas. I'll continue working on this. > I've also uploaded your package to the luxor-contrib > site so it's easier to download it for further study. > See > http://sourceforge.net/project/showfiles.php?group_id=64067 > (look for the luxor2 package). > > I'm currently a little stretched so I can't really > continue working on Luxor for now. I hope to find more > time in about two or three weeks. > > Once I get started again I plan to look at SwiXml > online @ http://www.swixml.org and see if some ideas > such as converters and heavy use of reflections may > help out Luxor. You might also have a look for some > ideas. > > I also plan to look at Sulu online @ > http://sulu.sourceforge.net and see if it makes sense > to merge the codebase. You might also have a look for > some ideas. > I'll look at the urls. If I have any comments I'll post them. > To wrap up I urge you to go ahead with lets say a > new and fresh luxor2 branch. Ok. After some cvs study (on how to create branches) I'll do that tomorrow. |
From: Gerald B. <ge...@va...> - 2004-06-14 20:58:09
|
Hello Anakreon, > I'll continue working on this. Good to hear it. Please keep up your great work. > I'll look at the urls. If I have any comments I'll > post them. I encourage you to do so. I think looking at different approaches and discussing them will help us create a better XUL toolkit. > Ok. After some cvs study (on how to create branches) > I'll do that tomorrow. Just to clear up a possible misunderstanding. By creating a branch I mean just check in a new fresh module using for example luxor2 for the module name. I mean a branch in the source tree not in the strict CVS sense. Hope this makes sense and so for the confusion. - Gerald |
From: Anakreon <ana...@ya...> - 2004-06-14 21:19:04
|
Gerald Bauer wrote: > Hello Anakreon, > > >>I'll continue working on this. > > > Good to hear it. Please keep up your great work. > > >>I'll look at the urls. If I have any comments I'll >>post them. > > > I encourage you to do so. I think looking at > different approaches and discussing them will help us > create a better XUL toolkit. I looked at the first one and downloaded the second. I have comments for the first: ====================== http://www.swixml.org ===================== Luxor will be small. Also, the focus on a specific toolkit is an advantage if by supporting many toolkits could lead to sloppy code. This should not be the case for luxor and depends after all on the developers. Also, the code generation technique could be used to generate source code which will be used instead of the xml files. This is usefull only when the xml is static and if deploying luxor along with the application is a problem. This needs more thought about the implementation details and if needed to be implemented after all. Having tag names to be clases and attributes as methods has nothing to do with XUL and I don't find it apealing. I prefer the XUL whay. After all someone could use Jelly for this. The second project needs carefull study since is similar to luxor in it's aproach and goal. > > Just to clear up a possible misunderstanding. By > creating a branch I mean just check in a new fresh > module using for example luxor2 for the module name. > > I mean a branch in the source tree not in the strict > CVS sense. Hope this makes sense and so for the > confusion. Oups. To late. I took it literaly and created such a branch. I'll see how branches can be removed and how modules are created and do it tomorrow when my mind is clear. Goodnight, I'm going to sleep. Anakreon. |
From: Gerald B. <ge...@va...> - 2004-06-14 21:36:47
|
Hello Anakreon, Thanks for your comments on SwiXml. You might also wonna read the interview with SwiXml project lead Wolf Paulus online @ http://xul.sourceforge.net/post/2004/03/xul_titan_interview_wolf_paulus_of_swixml_and_theodore_fame.html > The second project needs carefull study since is > similar to luxor in it's > aproach and goal. Unfortunately, I didn't have a chance yet to look at Sulu closely. However, I mailed Sulu project lead Son To and Son agreed to sign up for a XUL titan interview. I will post the first part of the interview shortly. > Oups. To late. I took it literaly and created such a > branch. I'll see how branches can be removed > and how modules are created and do it tomorrow when > my mind is clear. Sorry for the confusion. Don't worry about deleting the CVS branch. Just leave it as it is and create a new fresh module using whatever directory structure you think is best. - Gerald |