Re: Re: [PATCH] Swixml - Extending DefaultFactory

My 2c, after thinking about it, I agree registering tags in Java code is
the best way.  For those that like xml config, you could easily write a
helper class that loads the definitions from xml, but for those of us that
like the simplicity and speed, Java registration works fine.  I think Wolf
is right in trying to keep swixml as simple as possible and avoiding any
additional performance hinderences.

I think the proposed changes sound fine; my biggest need is additional
flexibility in changing behavior like linking actions and tag id's to
public variables, however these new options should be completely, well,
optional, and 100% backwards compatible.

On the topic of speed, how difficult would it be to use sax instead of
jdom?  My guess is it would be more code, but improve both speed and
resource usage by a bunch, not to mention get rid of a dependency :)

Finally, thanks for the hard work wolf! :)

Don

On Fri, 24 Oct 2003, Wolf Paulus wrote:

> I do understand and appreciate the requests for structural changes and new
> features for the next Swixml version. Swixml 2, (the development has already
> started) will include or enable almost the things we have talked about in
> this forum; to name the most important:
>
> SWT support
>
> Layout support (i.e. introduction of a new Layout tag)
>
> Easier instantiation for tag implantations that use constructors other than
> a default constructor (sending dynamic parameter instances to a tag
> constructor)
>
> Model instantiation and initialization through XML for mostly static widget
> model data (i.e. combo boxes, with static data).
>
> Improved support for custom tags and tag libraries (plug-ability).
>
> Etc.
>
>
>
> However, all these things will be implemented in a way fitting the overall
> Swixml strategy.
>
>
>
> Regarding Gerald's comment, I'd like to point out that even with the current
> Swixml release, there is no need to recompile or "tweaking the kernel" to
> plug-in your own tags. The Swixml site shows in one of the samples how to
> implement your own tags:
>
> http://www.swixml.org/samples/index.html
>
> 6. Extend the Swixml TagLibrary with your own tags
>
>
>
> getTaglib().registerTag( "xpanel", XPanel.class );
>
> Which allows for compile-time type checking, an advantage one does not have
> in scripting languages. Swixml exposes its TagLibraries and allows for
> modifications. To conclude, Swixml will grow in functionality but not in
> size and it will expand into SWT space without becoming slower.Regards
> Wolf Paulus--Wolf PaulusC a r l s b a d   C u b e
> smailto:[email protected] NOTICE:This message is
> intended only for the use of the individual or entity towhich it is
> addressed, and may contain information that is privileged,confidential and
> exempt from disclosure under applicable law.If you are not the intended
> recipient, please contact the sender by replyemail and destroy all copies of
> the original message.
>
>
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>