Re: [Xswt-developer] Thanks and regression testing
Brought to you by:
dvorme
Menu
▾
▴
Re: [Xswt-developer] Thanks and regression testing
|
From: David J. O. <dj...@co...> - 2006-06-23 05:03:18
|
Hallvard Tr=E6tteberg wrote:
> David,=20
>
> =20
>>> In our case, I think we could handle it be reversing the collaboratio=
n=20
>>> between classes
>>>
>>> =20
>> That might be the best solution.
>> =20
>
> I've now implemented (and tested, but not committed, yet) it so that
> XswtPlugin modifies static fields in ClassBuilder, DataParser and XSWT,=
by
> means of public static methods. This means that these classes somehow m=
ust
> trigger processing of plugin extensions, before the first instance star=
ts
> operating. I've modified XSWT to do this using reflection and a naming
> convention for the methods that process the various extension points, a=
s
> shown below. There is no reference to XswtPlugin left, besides the stri=
ng in
> the Class.forName() call. Care must be taken so this method is called b=
efore
> any DataParser, ClassBuilder or XSWT instance is created. Currently the
> method is called in XSWT's constructor, but it could also be called fro=
m
> DataParser's and ClassBuilder's constructors.
>
> public static void processXswtPluginExtensions() {
> if (xswtPluginExtensionsProcessed) {
> return;
> }
> xswtPluginExtensionsProcessed =3D true;
> try {
> Class c =3D
> Class.forName("com.swtworkbench.community.xswt.XswtPlugin");
> Object xswtPlugin =3D c.getMethod("getDefault", new
> Class[]{}).invoke(null, null);
> Method[] methods =3D c.getDeclaredMethods();
> for (int i =3D 0; i < methods.length; i++) {
> Method method =3D methods[i];
> if (method.getName().startsWith("process")
> && method.getName().endsWith("Extensions")) {
> method.invoke(xswtPlugin, null);
> }
> }
> } catch (Exception e) {
> }
> }
> =20
Without seeing your code I can't comment in detail, but is there a way=20
to not use static fields? Designers tend to view static fields as evil=20
and in the context of Eclipse, this is magnified. If there are three=20
plugins A, B, and C, and B and C depend on A. Assume further that A, B,=20
and C are all from different vendors. If A is configured by use of=20
static fields, then this means that A's configuration is changeable=20
globally for everyone by anyone. This means that if B changes A's=20
configuration, C's configuration just changed also without C's knowledge=20
or consent.
Maybe this situation doesn't apply to what you did (I can't tell without=20
seeing the code), but I wanted to make sure we discussed it.
>>> Perhaps we need several kinds of projects: =20
>>> =20
>> Hmmmm.... I generally agree except that I think that #1=20
>> should still be a plugin project. Not because it has to be=20
>> but because this makes it easier to manage the build and=20
>> deployment story using the PDE.
>> =20
> OK.
> =20
>> I agree. And I think that this is the release to do this=20
>> kind of renaming.
>> =20
>
> Your editor work depends on the Callisto release, right? This means tha=
t the
> release will be in August?
Callisto goes live this coming week. :-) Unfortunately my editor won't=20
be ready by then, but I'm getting close to having the same functionality=20
as the XSWT preview had, but rewritten using the editor infrastructure. =20
Once that is done I think I'd like to think about putting together some=20
documentation and packaging a new release.
> What features in XSWT, the XSWT view and editors
> must be finished by then. I would like to ensure that scripting works w=
ith
> data binding, but besides that I have few plans before taking a months
> vacation in July. What things would you like me to look at?
> =20
Any of the following:
1) The Great Renaming that we discussed. (Making all plugins and=20
packages start with net.sf.xswt.)
2) The XSWT style sheet proposal / implementation. Or maybe less=20
ambitiously but just as importantly, how this would implement a module=20
system for the XSWT language and how this will integrate with=20
scripting. :-) Let's do design by listing use-cases and actual XSWT=20
code we would like to be able to write to implement those use-cases like=20
we did for the data binding implementation.
3) Start coming up to speed on the XSWT editor code base.
4) Documentation.
>> Yeeeeaaaah. I get it now. I sure hope that XSWT gets that=20
>> successful that folks start using it for things like that. :-)
>> =20
> I have hacked together a pnuts extension module, based on XOM (XML pars=
ing)
> + TagSoup (converts ugly HTML to XHTML), and based on that, it was very=
easy
> to write an XSWT file where you could insert a URL, an XPath expression=
and
> populate a List with the result. There's no API for posting data, but i=
t
> supports simple UIs for fetching and displaying data from GET-based web
> services.
> =20
This would make an awesome screencast! :-)
> <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> <xswt xmlns:x=3D"http://sweet_swt.sf.net/xswt">
> <x:import>
> <package name=3D"java.lang"/>
> <package name=3D"org.eclipse.swt.widgets"/>
> <package name=3D"com.swtworkbench.community.xswt.scripting"/>
> <package name=3D"org.eclipse.swt.layout"/>
> </x:import>
> <composite>
> <layout x:class=3D"gridLayout" numColumns=3D"3"/>
> <text x:id=3D"url" text=3D"http://www.idi.ntnu.no/~hal/
> "/>
> <text x:id=3D"xpath" text=3D"//html:a/@href
> "/>
> <button text=3D"Go" selectionListener=3D"xpathhandlers.go"/>
> <list x:style=3D"V_SCROLL" x:id=3D"result">
> <layoutData x:class=3D"gridData" horizontalSpan=3D"3"
> horizontalAlignment=3D"FILL" grabExcessHorizontalSpace=3D"true"/>
> </list>
> <script x:id=3D"xpathhandlers" lang=3D"pnuts">
> function go(event) {
> url =3D id::url.text.trim();
> xpath =3D id::xpath.text.trim();
> get(url, xpath);
> }
> function get(url, xpath) {
> =09
> use("com.swtworkbench.community.xswt.pnuts.modules.xml");
> nodes =3D xml::xom(url, xpath);
> result =3D project(nodes,
> function(node)node.value);
> id::result.items =3D
> result.toArray(String[result.size()]);
> }
> </script>
> </composite>
> </xswt>
> =20
Wow.
Best regards,
Dave Orme
|
