Frank, Looks like you know that Parser already better than I do ;-) You are absolutely correct with your analysis and using the JComponent's built-in map seems to be a good compromise when considering system resources, parse-time, etc.
Again, I'm not afraid of the work required to implement features like the one Jarno suggests but have to consider the size this adds to the swixml.jar and more importantly the consequences for the runtime behavior. Everything we add to the parser-process will eventually delay the appearance of the GUI. I.e. the time between a button gets pressed and a property-dialogs appears gets a little longer. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Frank Mei?ner > Sent: Tuesday, April 08, 2003 11:48 PM > To: [email protected] > Subject: Re: [Forum] Another way to express attributes? > > > Hello, > > the idea is not bad and I'm not sure this will be *that* much work. At > least if we stick to JComponent, there is a convenient > putClientProperty(Object key, Object value) method. The parser (in > getSwing(Element, Object) does already remove all attributes it knows > about. So, we have only to change the iteration printing errors (about > not applying attribute for tag xxx) to call putClientProperty(...) if > the returned element is some child of JComponent (as it mostly -- not > usual -- is). Wolf, correct me if I'm wrong :) I'm not sure I'm already > using the correct source code you sent... If we use tags of course we > have to change getSwing a bit, starting perhaps with the name :) This > function (getElementOrAttribute?) has to check if it is able to cope > with the element (e.g. is able to return some swing element) or give > it's value back. > > Of course, the problem remains if element is'nt a child of > JComponent... > > Besides this, I think it is'nt a bad idea allthough we have to be > careful if we want sometimes provide a DTD: if there are *attributes* > with different possible values this is easily covered by a DTD. If we > use tags as attributes all tags with the same name must have the same > content-type (what is valid inside the tag and what's not -- if we have > multiple tags with the same name, this will most likely boil down to > CDATA). This will be a minor problem because the one to deal with the > content (which will most likely be a String) is the user code... > > Sorry I did not provide some input earlier, I was somewhat busy with > other problems :) > > Yours, > > Frank > > Wolf Paulus wrote: > > Jarmo, > > Thanks for submitting another good idea. Unfortunately, nobody > did comment > > on it so far ... > > > > I think this could be helpful and I especially like the idea > with the custom > > attributes. However, this would put some more workload on the > parser and the > > creation of hashmaps for every tag with un-recognized attributes also > > doesn't make Swixml any faster. Still, like I said, I consider > both ideas as > > helpful improvements. > > > > Let's hear if some more opinions ... > > > > > > > >>-----Original Message----- > >>From: [EMAIL PROTECTED] > >>[mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] > >>Sent: Monday, April 07, 2003 2:48 AM > >>To: [email protected] > >>Subject: [Forum] Annother way to express attributes? > >> > >> > >>Hi all, > >> > >>Sometimes it would be nice to give attribute with XML special > >>characters. We can > >>express it by using the XML encoding scheme, but it is not very clear. > >> > >>I wonder if it is possible to give the attributes like this: > >> > >><dialog> > >> <attr name="id">1232132</attr> > >> <attr name="name"><![CDATA["dialog<name>"]]></attr> > >> <attr name="modal">true</attr> > >></dialog> > >> > >>Perhaps this way we can also provide user attributes too. I.e. > >>attributes that > >>are not regognized by swixml are put to a HashTable for lookup in > >>application > >>code. > >> > >>What do you think? > >> > >>//jarmo > >> > >> > >> > >>_______________________________________________ > >>Forum mailing list > >>[email protected] > >>http://mars.lunarpages.com/mailman/listinfo/forum_carlsbadcubes.com > >> > >> > > > > > > > > _______________________________________________ > > Forum mailing list > > [email protected] > > http://mars.lunarpages.com/mailman/listinfo/forum_carlsbadcubes.com > > > > > > > > _______________________________________________ > Forum mailing list > [email protected] > http://mars.lunarpages.com/mailman/listinfo/forum_carlsbadcubes.com > >
