Re: [Xswt-developer] extensions

[David O. <dj...@co...>]

>> Without seeing your code I can't comment in detail, but is
>> there a way to not use static fields?  Designers tend to view
>> static fields as evil and in the context of Eclipse, this is
>> magnified.
>> ...
>> Maybe this situation doesn't apply to what you did (I can't
>> tell without seeing the code), but I wanted to make sure we
>> discussed it.
>
> When a plugin contributes an extension, it will affect the extended plu=
gin
> "globally", similar to changing a static field. In this case, it adds
> objects to a list, which the receiver uses for some purpose. There are
> three
> contributions: IDataParser, imports to ClassBuilder and ScriptingEngine=
s.
> I
> think we should decide case by case if the technique is OK. I don't hav=
e
> any
> strong feeling about this, there are two requirements: ensuring XSWT ca=
n
> run
> without the XswtPlugin and support these extensions.

Another thought:  We currently require the developer to create an instanc=
e
of the XSWT object, which itself contains an instance of DataParser and a
ClassBuilder.  Is it possible for this configuration to be done on these
instance variables and not using extension points?  Then all
plugin-specific configuration could be confined to just that plugin's
scope.

I imagine this might cause problems for scripting?

If we can choose this way of configuring XSWT, it seems like it might be =
a
more lightweight way to do it than using extension points?

Which way do you think would be simpler and more elegant?

>> 1) The Great Renaming that we discussed.  (Making all plugins
>> and packages start with net.sf.xswt.)
>
> I'll leave this one to you. It's better done without too many people
> involved.

:-)  Totally agree.

>> 2) The XSWT style sheet proposal / implementation.
>
> I'll take a look at your suggested syntax, and see if I get some
> inspiration
> :-) I think my last thought on this was that it would be a lot easier i=
f
> we
> had an element tree, instead of doing pull parsing (my own framework
> supported copying/inserting/transforming nodes from other parts of the
> tree).

Agreed.  KXML is also no longer supported.  Yu You suggests that we switc=
h
to Eclipse's XML parser from the eRCP project.

>> 3) Start coming up to speed on the XSWT editor code base.
>
> With only two weeks left before my vacation, I think I'll have to wait.

:-)  It's easier than you think, especially if we can set up a Skype/VNC
code jamming session so I can help you get started.  But it would probabl=
y
be better to wait until after we ship our next release (which I think I'l=
l
label a beta since there are so many changes).

>> 4) Documentation.
>
> Are you thinking of a separate document or as javadoc?

I'm thinking of a Programmer's Guide.  Basically, expanding the "getting
started guide" I have on my web site into a full tutorial covering all of
the XSWT language features plus scripting and data binding.

This is one of my next tasks once I've got the code base back in a
releasable state; if you'd like to help, that might be fun. :-)

>> > I have hacked together a pnuts extension module, based on XOM (XML
>> > parsing) + TagSoup (converts ugly HTML to XHTML), ... it supports
>> > simple UIs for fetching and displaying data from GET-based web
>> services.
>> >
>> This would make an awesome screencast!  :-)
>
> I'll try to think of a good example, to inspire people.

Hmmm... Thinking randomly: Maybe something that can search Amazon and
return the results in a UI?  I'll post again if I have more ideas...


Regards,

Dave