Re: Is Swixml a rich (or smart) client?

Nope, you got it Kate. I suppose it was more of a "I
think it does, but let me be sure" question. I don't
see a problem with it either.

Now, how about this setup. I want to make a plugin
that packages the swixml engine. I will provide an
extension point so that other plugins can extend it
and make use of the swixml engine in some manner. Is
it possible that each plugin, when loaded, can make
use of the engine, meaning, the way the plugin that
provides the extension point would work is that it
would loop through any resolved extensions, and for
each one it would get some dynamic values, in this
case the xml file(s) used to render its dialog(s),
etc. Can you use a single instance of the swixml
engine to make many calls to it, each time passing a
different xml file in it and getting I presume a
container with the swixml xml rendered into it? I am
not sure how it works, but I would envision my
extension point requiring every swixml plugin to
provide a JPanel, and on this jpanel the swixml engine
takes the plugins xml and generates the UI for it.
Later on, some menu item or button or something is
clicked on which pops up this dialog and its already
done, ready to use (or might be generated at that
time...).

That possible?

--- masukomi <[email protected]> wrote:
> Umm... I'm confused.
> 
> I don't see why it wouldn't be possible. But, that's
> why I'm confused.
> As long as the swixml classes are available to the
> plug-ins I don't see  
> why not.
> 
> is the question more something along the lines of is
> it possible to let  
> them do dialogs but not menus? Answer would be no.
> 
> Enabling them to do menus and such would be easy.
> But obviously you  
> don't want that.
> 
> I feel like I'm missing some crucial piece of the
> question. I think I'm  
> not seeing what it is that you think might prevent
> such a thing from  
> working.
> 
> -Kate
> 
> 
> On May 10, 2004, at 5:15 PM, Kevin Duffey wrote:
> 
> > I got a question for Kate/Wolf, since ya'll know
> about
> > my plugin engine project. I am working (rather
> slowly
> > due to time) on a pluggable UI Framework.
> Initially it
> > will have a core set of plugins that provide a
> menuing
> > capability. Using extension points, other plugins
> add
> > menu items and toolbar buttons through extensions
> via
> > the plugin.xml file of each plugin. They don't
> > hard-code them using Swing code. This is sort of
> like
> > swixml, only I dont wish to copy swixml. My intent
> is
> > to provide a "docking" place for plugins to add
> > clickable links (menu items, toolbar buttons, etc)
> > that can then activate their plugin. Each plugin
> may
> > provide their own dialog UI. This is where my
> question
> > comes in.
> >
> > I am wondering if a plugin could make use of
> swixml to
> > build its dialog, which is snapped in to my UI
> > Framework at a given extension point. In other
> words,
> > a plugin would have access to the swixml library
> > somehow (most likely via an application classpath
> so
> > more than one plugin can use it without each
> having to
> > distribute the swixml library) and be able to use
> it
> > to generate dialogs and such, but they wouldn't
> use it
> > to add menu items or toolbar buttons.
> >
> > Is something like this possible? I think it should
> be,
> > and it may be great to package the swixml library
> and
> > UI RAD editor to build UI plugins rapidly. It
> still
> > wont help for some things like help system that
> may
> > use JavaHelp or HTML viewer, but it should help in
> > other areas.
> >
> > Thanks.
> >
> > --- Frank Meissner <[email protected]> wrote:
> >> karim virgil wrote:
> >>>  Hi everybody,
> >>> I post this message because I would like to have
> >> some advices from the
> >>> Swixml communauty.
> >>>
> >>> Currently,  I'm doing some research on the rich
> >> (smart) client domain because
> >>> I'll like to develop an application
> >>> that can be deployed and updated easily but more
> >> user-friendly than the
> >>> HTML.
> >>>
> >>> Naturally, I found the Mozilla + XUL (and
> >> javascript) solution very attractive
> >>> because it meets my needs
> >>> completely. There is only one drawback : This
> >> solution obliges the user
> >>> to use Mozilla but I can't impose this
> >>> constraint to him.
> >>>
> >>> So, I was looking for another solution and I
> found
> >> this Internet Site :
> >>> http://xul.sourceforge.net/counter.html
> >>>
> >>>
> >>> As far as I'm concerned, I think that swixml won
> >> this challenge because
> >>> the esthetics of the interface is
> >>> pleasant and this in few lines of code.
> >>>
> >>> After, I found the Web journal of Wolf Paulus
> >> (http://www.carlsbadcubes.com/blog/index.html)
> >> where
> >>> it's
> >>> written that Mr Galbraith said at the San Diego
> >> Software Symposium that
> >>> he thought SwixML is the most mature
> >>> XUL/Swing offering.
> >>>
> >>>
> >>> After doing some research on how Swixml works, I
> >> found that the xml file
> >>> that describe the UI is interpreted by
> >>> the SwingEngine initialised in a .java file and
> >> launched by a JVM.
> >>>
> >>> Can we consider that Swixml really acts like a
> >> rich client?
> >>>
> >>> In other words, is swixml a rich client or
> "only"
> >> a way to describe
> >>> swing interface in xml ?
> >>>
> >>> What are the advantages to create an UI using
> XML
> >> rather than a hard coded
> >>> one?
> >>
> >> IMHO the biggest advantage is the separation of
> GUI
> >> and business logic.
> >> You can
> >> a) have very different GUIs serving the same
> purpose
> >> but looking totally
> >> different
> >> b) may have customer specific GUI files which may
> >> show more ore less
> >> available business logic to the customer
> (customer
> >> pays more and sees more)
> >> c) design in rapid prototype way, e.g. have a
> >> business logic skeleton
> >> which is used by your GUI e.g. in a session with
> >> your customer until the
> >> customer is satisfied
> >> d) design your GUI in a more "natural" way (at
> least
> >> IMHO) because if
> >> you have a complicated GridBagLayout with a lot
> of
> >> constraints, insets
> >> and the whole bunch of glue you easily get lost
> >>
> >>>
> >>> What I think is that swixml can't be considered
> as
> >> a smart client alone
> >>> but It really makes the deal if it's
> >>> combined to Java Web Start (so Java Web Start +
> >> swixml.jar == mozilla browser
> >>> behaviour with XUL).
> >>
> >> No, that would do mozilla less a favour. Mozilla
> >> IMHO relies on its GUI
> >> glueing its business logic with javascript, which
> >> is'nt easily doable
> >> with swixml. Even some of the business logic is
> >> realized through
> >> javascript in mozilla. This is not the intention
> of
> >> swixml. IMHO swixml
> >> goes well if you keep the business logic somewhat
> >> isolated: have
> >> components take care of themself, do a job,
> nothing
> >> more, nothing less.
> >> Then access these components through the
> swixml-GUI
> >> like Actions. Thus,
> >> your backend-logic (do'nt know if this is the
> right
> >> name) provides basic
> >> services (network connection, data sources, ...),
> >> Actions (menu-items,
> >> buttons, ...) do the business-logic and glue the
> 
=== message truncated ===



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover