Wolf,

The only way to really do a "pluggable concept" that allows for 
flexibility is to allow the end developer the ability to register custom 
tags for his/her application simply and automatically.

I have seen numerous requests in the forum that ask for extensibility. 
This provides it.

I will be also using this concept to extend the requests in the forum 
for "Layouts".  So far, my research shows that adding any layout type that 
anyone wants to use will be fairly simple.

Provide a "Layout" entry and a "LayoutData" entry in the propertiesc file.
When we encounter that tag, we can then process the appropriate registered 
layout converter.

I am using the same concept as Localization routines. The Localization 
routines adds flexibility by storing your Localized Strings seperately, 
outside the application. 

Same thing with the properties file.

BTW: Why not replace java?  Isn't that really what we are doing anyways?
We are extending Java by replacing Java calls with XML "scripting" to 
build the gui.

That is all this is really doing anyways.

The only extra time the routine takes is to have SAX parse the doc.
This is a pretty quick action, loaded once per program instantiation and 
allows for the maximum, long term, flexibiity for developers.

If the developer wants to load a different properties file each and 
everytime, they can.  That doesn't mean you have to. We are just giving 
them the option. 

Basically, the coding won't have to change, just which classes are used to 
build the tags.  

Those who want to over-ride the default tags with different class can 
simply and easily, without duplicating code in every project they run.
E.g. using register("Menu","somenewclass.class")

When a user wants to add new tags, or over-ride other tags, all they have 
to do is modify the properties file.  Not the code.

The code therefore stays frozen.  Less maintainence, more reliability and 
more flexibility.

Brian

On 10/24/2003 - 08:33:51, "Wolf Paulus" said:
> >From what I have seen and learned so far I'm not really in favor of
> registering Tags by parsing XML documents. While this would probably be a
> one time hit, parsing still takes time and we should only add to the 
already
> long startup time where this is absolutely necessary.
> 
> Besides a potential performance issue, I don't see what we gain. In a 
recent
> project, we registered about 10 custom Swixml tags, some new and some 
were
> just overwriting/replacing the default tags. All this happens 
dynamically at
> runtime. The implementation of a XYZ tag may change with every 
instantiation
> of a SwingEngine class - every time a dialog i.e. is rendered.
> 
> 
> 
> I understand that this request is mostly driven by the need to support 
SWT
> along side JFC - to be clear, I support those efforts and Swixml 2.0 
design
> will be enabling and/ or supporting SWT - however, I don't want to 
replace
> Java with XML and this stuff definitively goes into this direction.
> 
> <tag name="Applet" factory="javax.swing.JApplet" />
> 
> To me, this looks like then indrodution of a script language into Swixml,
> which is not very likely to succeed. Swixml was always thought to be 
plain,
> simple, small, and fast.
> 
> This is not Mozilla XUL nor Luxor.
> 
> Wolf
> 
> "Brian P Michael" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Don,
> >
> > I am working on quite a few changes to the guts of Swixml so
> > that multiple engines, including SWT and Swing can be used.
> >
> > I will have the changes completed and tested within a week or so.
> >
> > One of the major changes that I am working on is to dynamically
> > register the
> > factories and converters via an file like this:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <swixml>
> >   <engine type="swing">
> >      <tag name="Applet" factory="javax.swing.JApplet" />
> >      <tag name="Button" factory="javax.swing.JButton" />
> >      <tag name="ButtonGroup" factory="javax.swing.ButtonGroup" />
> >      <tag name="HBox" factory="org.swixml.swing.XHBox" />
> >      <tag name="VBox" factory="org.swixml.swing.XVBox" />
> >      <tag name="Checkbox" factory="javax.swing.JCheckBox" />
> >      <tag name="CheckBoxMenuItem"
> > factory="javax.swing.JCheckBoxMenuItem" />
> >      <tag name="ComboBox" factory="javax.swing.JComboBox" />
> >      <tag name="Component" factory="javax.swing.JComponent" />
> >      <tag name="DesktopPane" factory="javax.swing.JDesktopPane" />
> >      <tag name="Dialog" factory="org.swixml.swing.XDialog" />
> >      <tag name="EditorPane" factory="javax.swing.JEditorPane" />
> >      <tag name="FormattedTextField"
> > factory="javax.swing.JFormattedTextField" />
> >      <tag name="Frame" factory="org.swixml.swing.JFrame.class);
> >      <tag name="Glue" factory="org.swixml.swing.XGlue" />
> >      <tag name="GridBagConstraints"
> > factory="org.swixml.swing.XGridBagConstraints" />
> >      <tag name="InternalFrame" factory="javax.swing.JInternalFrame" />
> >      <tag name="Label" factory="javax.swing.JLabel" />
> >      <tag name="List" factory="javax.swing.JList" />
> >      <tag name="Menu" factory="javax.swing.JMenu" />
> >      <tag name="Menubar" factory="javax.swing.JMenuBar" />
> >      <tag name="Menuitem" factory="javax.swing.JMenuItem" />
> >      <tag name="Panel" factory="javax.swing.JPanel" />
> >      <tag name="PasswordField" factory="javax.swing.JPasswordField" />
> >      <tag name="PopupMenu" factory="javax.swing.JPopupMenu" />
> >      <tag name="ProgressBar" factory="javax.swing.JProgressBar" />
> >      <tag name="RadioButton" factory="javax.swing.JRadioButton" />
> >      <tag name="RadioButtonMenuItem"
> > factory="javax.swing.JRadioButtonMenuItem" />
> >      <tag name="OptionPane" factory="javax.swing.JOptionPane" />
> >      <tag name="ScrollPane" factory="javax.swing.JScrollPane" />
> >      <tag name="Separator" factory="javax.swing.JSeparator" />
> >      <tag name="Slider" factory="javax.swing.JSlider" />
> >      <tag name="Spinner" factory="javax.swing.JSpinner" />
> >      <tag name="SplitPane" factory="org.swixml.swing.XSplitPane" />
> >      <tag name="TabbedPane" factory="org.swixml.swing.XTabbedPane" />
> >      <tag name="Table" factory="javax.swing.JTable" />
> >      <tag name="TableHeader" factory="javax.swing.JTableHeader" />
> >      <tag name="TextArea" factory="javax.swing.JTextArea" />
> >      <tag name="TextField" factory="javax.swing.JTextField" />
> >      <tag name="TextPane" factory="javax.swing.JTextPane" />
> >      <tag name="ToggleButton" factory="javax.swing.JToggleButton" />
> >      <tag name="Tree" factory="javax.swing.JTree" />
> >      <tag name="Toolbar" factory="javax.swing.JToolBar" />
> >      <converter class="Action.class"
> > converterlib="org.swixml.swing.Converters.ActionConverter" />
> >      <converter class="Border.class"
> > converterlib="org.swixml.swing.Converters.BorderConverter" />
> >      <converter class="Color.class"
> > converterlib="org.swixml.swing.Converters.ColorConverter" />
> >      <converter class="Dimension.class"
> > converterlib="org.swixml.swing.Converters.DimensionConverter" />
> >      <converter class="Font.class"
> > converterlib="org.swixml.swing.Converters.FontConverter" />
> >      <converter class="Image.class"
> > converterlib="org.swixml.swing.Converters.ImageConverter" />
> >      <converter class="Icon.class"
> > converterlib="org.swixml.swing.Converters.ImageIconConverter" />
> >      <converter class="ImageIcon.class"
> > converterlib="org.swixml.swing.Converters.ImageIconConverter" />
> >      <converter class="Insets.class"
> > converterlib="org.swixml.swing.Converters.InsetsConverter" />
> >      <converter class="KeyStroke.class"
> > converterlib="org.swixml.swing.Converters.KeyStrokeConverter" />
> >      <converter class="LayoutManager.class"
> > converterlib="org.swixml.swing.Converters.LayoutConverter" />
> >      <converter class="Locale.class"
> > converterlib="org.swixml.swing.Converters.LocaleConverter" />
> >      <converter class="Point.class"
> > converterlib="org.swixml.swing.Converters.PointConverter" />
> >      <converter class="String.class"
> > converterlib="org.swixml.swing.Converters.StringConverter" />
> >      <converter class="boolean.class"
> > converterlib="org.swixml.swing.Converters.PrimitiveConverter" />
> >      <converter class="int.class"
> > converterlib="org.swixml.swing.Converters.PrimitiveConverter" />
> >      <converter class="long.class"
> > converterlib="org.swixml.swing.Converters.PrimitiveConverter" />
> >      <converter class="float.class"
> > converterlib="org.swixml.swing.Converters.PrimitiveConverter" />
> >      <converter class="double.class"
> > converterlib="org.swixml.swing.Converters.PrimitiveConverter" />
> >   </engine>
> > </swixml>
> >
> > This should make it easier to register any tag and factory that you
> > wish.
> >
> > Sincerely,
> >
> > Brian P Michael
> >
> > PS.  Were you ever involved in a company called AlgoSol.
> >
> >
> > On Thursday, October 23, 2003, at 03:49  PM, Don Brown wrote:
> >
> > > I made several small changes to DefaultFactory to make it possible to
> > > extend; basically, I removed the final modifier from the class and
> > > template variable.
> > >
> > > Here's my use case:  I want my custom tags, and some swing tags, to 
be
> > > created by my inversion of control (IoC) framework (Spring -
> > > http://www.springframework.org).  This lets my plugins declare what
> > > resources they will need through JavaBean setters, and spring, at 
call
> > > time, will create the plugin and provide it with its resources.
> > >
> > > The best way I could see to accomplish this was to extend
> > > DefaultFactory
> > > and override its newInstance() method, leaving all the other method
> > > implementation to DefaultFactory.  Unfortunately, I discovered
> > > DefaultFactory and the key template variable are declared final.  I
> > > think
> > > there is value in making it possible to extend DefaultFactory for use
> > > cases such as mine.
> > >
> > > My modified DefaultFactory:
> > > http://www.twdata.org/dakine/DefaultFactory.java
> > >
> > > Comments?
> > >
> > > Don
> > >
> > >
> > > _______________________________________________
> > > Forum mailing list
> > > [email protected]
> > > http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
> > >
> > >
> > Sincerely,
> >
> > Brian P Michael
> > 630-897-8364 x17
> > [EMAIL PROTECTED]
> >
> >
> >
> 
> 
> -------------------------------------------------------------------------
---
> ----
> 
> 
> >
> >
> 
> 
> -------------------------------------------------------------------------
---
> ----
> 
> 
> > _______________________________________________
> > Forum mailing list
> > [email protected]
> > http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
> >
> 
> 
> 
> 
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
> 
> 





--

Reply via email to