Re: [Xswt-developer] extensions
Brought to you by:
dvorme
|
From: David O. <dj...@co...> - 2006-06-26 17:29:08
|
>> 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 |