What about a wildcard import to save typing effort?

<gwt:import class='com.google.gwt.user.client.ui.'/>

The code would throw an error if and only if there was an ambiguous reference to an element. This could be fixed by explicitly specifying the package on the element itself:

<gwt:TextBox? gwt:package="com.google.gwt.user.client.ui"> ...

Another question: what about having a way to disambiguate the control IDs so that more than one of a declarative control could be used on a page? Perhaps the generator could prepend a specific string to each control ID?

re: ImageBundle? support.

I think that the image bundles should be defined externally as they are now, but imported as controls.

The syntax to use it in a page would then be:

<gwt:MyImageBundle? image="myImage" />

re: i18n

It might be good to think about a generic data-binding model might fit into this functionality later on. I don't know if this would be outside future scope of declarative UI in the future, but i18n could be looked at as a subset of databinding and looking to something like the Velocity templating engine (or a better one if it exists) as something to copy might be a good idea.

What about binding? Expression Language bindings would be linked with client side "Backing Beans" and resolved by the generator. For example:

@GwtBean?(name="registerAction", scope=SESSION) class RegisterAction?{

public Person getPerson(){...}

public void register(){...}

}

<gwt:TextBox? value="#{registerAction.person.name}" /> <gwt:Button clickListener="#{registerAction.register}" />

@andres What scopes would you envisage ?

@all Does the binding happen on the server or on the client ?

@mmastrac: I agree that wildcards would be a very good thing. The resolution rules would be the same as in Java source.

I probably shouldn't have used 'id' as the attribute for a Widget's name. There is no generated HTML for a widget (though there can be inside a widget), so the id has no effect other than to tell the generator what name you want for it.

w.r.t. ImageBundle?: My concern is, "how do you bind an ImageBundle? to an existing widget, or HTML <img> tag?". For example, I want to be able to do:

• <gwt:Image src='myImageBundle.icon0'/>
• <gwt:HTML>foo <img src='myImageBundle.icon0'/> bar</gwt:HTML>

But I'm still trying to work out the best way to identify these constructs and associate them with the bundle. Incidentally, i18n string replacement has basically the same problem.

@andres: While something like this might be interesting, I'm really looking to keep code out of the template if at all possible. You can just as easily set these sorts of bindings up in code, where the IDE and other tools can help you write it correctly. And the templates are processed at compile-time, anyway.

@mP: Everything happens at compile-time. My real goal is to make it easier to write complex widgets and interact with designers, and to make the resulting code smaller and faster than you would write by hand :)

@Joel: We would have an special "Generation Time" interface to generate bindings:

interface BindingResolverCreator?{

/ invoked when a tag is open / void beginScope();

/ invoked when a tag is closed / void endScope();

/ invoked when a expression is found

• returns the name of the class implementing BindingResolver?

String createResolver(

TreeLogger? logger, GeneratorContext? context, String expressionToResolve

)throws UnableToCompleteException?;

}

interface BindingResolver?{

/ resolve an expression / Object resolve();

}

With a special annotation, we would fetch a BindingResolverCreator? to DclUi? implementation:

@BindingResolverCreatorName?("com.myiocframework.MyBindingResolverCreator?") public abstract class App extends Composite implements DeclUi?{...}

When BindingResolverCreators? are not specified, binding resolution is not enabled. Client side (or server side) IoC frameworks would implement BindingResolverCreator? to resolve expressions, using EL, OGNL, etc..

Another possible BindingResolver?:

interface BindingResolver?{

/ invoked in "get" expressions / Object resolveGet();

/ invoked in "set" expressions / void resolveSet(Object value);

}

instead of custom imports elements, why not use XML namespaces.

• It's the standard, meaning that other XML parser tools will still know how to handle elements.
• template author chooses the namespace prefix instead of the widget library developer.
• with an XSD for a given namespace, any sane XML editor (dreamweaver perhaps also) will allow element/attribute completion.
• namespace URI can be used for versioning of widget library

<g:ui xmlns="http://www.w3.org/1999/xhtml"
      xmlns:g="http://code.google.com/webtoolkit/client/ui/1.4"
      xmlns:mywidgets="urn://something/1.0">
<g:HTMLPanel>
  <div >
    <h1>Welcome</h1>
    <mywidgets:something  .../>
    <g:MenuBar>
      <g:MenuItem caption='file'/>
   
....

XSDs doesn't have to be in place at day one, since the above is perfectly valid XML, and the generator code will of course validate the structure anyways.

I agree with J.Alkjaer, XMLNS is valid XHTML

hi, I'm Flex/Java developer. I'm suing GWT Designer from Instantiations for GUI part of GWT related work which works really nice for most of widget/ui related work. I'm using Flex Builder for work with mxml declarative syntax and what I'm feeling here that GWT xml declarative language is going too far, it introduces additional classes (what is <gwt:HTMLPanel>???) while I think that being declarative means rather simplified access layer to existing framework, Using Flex SDK mxml solution I could think about GWT xml file being written:

<?xml version="1.0" encoding="UTF-8"?> <gwt:FlowPanel? xmlns:gwt="http://code.google.com/webtoolkit/client/ui/1.4"

xmlns="http://www.w3.org/1999/xhtml" xmlns:mywidgets="code.google.com.project.library">

<gwt:HTML>

<div class="banner" width="100%">

<img src="myLogo.gif"/>

Welcome to my application. It's really cool.

</div>

</gwt:HTML> <gwt:VerticalPanel? width="100%" height="100%">

<gwt:Label text="My label"

style="gwt-Label" dependentStyle="link"> MyLabel?

</gwt:Label> <gwt:HorizontalPanel? width="100%">

<gwt:Button text="CLICK ME"/> <mywidgets:ImageWidget? src="images/about.png"

width="40px" height="40px"/>

</gwt:HorizontalPanel?>

</gwt:VerticalPanel?>

(no script integration as noted in introductory post yet, just ui widgets)

If GWT solution could go that way and simply use decent code generator to transform xml to java code (wich is exactly how Flex BUilder works) it would be fine, Otherwise I think it will be just adding additional layer to GWT toolkit itself and maybe it will be problematic addition. I cannot see what I could gain from using declarative XML based language if I could quickly drag and drop GWT and 3rd party widgets within design view in GWT designer plugin for Ecipse now. Also using declarative XML should put several restrictions on UI elements behind it. For example in Flex SKD all widgets can have only one public no-arguments constructor. That simplifies translation from xml to generated code and also simplifies 3rd party software vendors efforts to write a decent IDE for use with such declarative language. I can only think that entire purpose of using declarative XML for GWT is to allow easy integration with existing or new IDEs. Think about Flex/Air, JavaFX and Silverlight - all of them will have (or already have) decent plugins for use with IDE's, As you can see I would rather see that "Open Questions" section topics are introduced and implemented.

but generally declarative language for GWT UI is just very good idea (I was always think that GWT Team should start with such project together wiht releasing GWT toolkit itself),

regards, Peter

@J.Alkjaer, Andres: I understand that we'll need to define a namespace, but I'm not yet 100% sure that it solves the same problem as the import tag. A namespace imports an entire class of elements, whereas we need to be able to specify a set of widgets that will be available as tags (the set of possible widgets would itself be open-ended, as it should be possible to bring in widgets from any library and package).

I realize this doesn't match perfectly with the normal use of XML. I've considered doing something like this instead:

<gwt:ui
  xmlns:g='http://.../com.google.gwt.user.client.ui'
  xmlns:other='http://.../com.somebody.else.client.widgets'
>
  <g:DockPanel>
    <other:MyWidget/>
  </g:DockPanel>
</gwt:ui>

This would require you to import one package per namespace, which kind of sucks, but at least it would eliminate namespace conflicts.

@gwt.team.jgw: Agree - a strict namespace per package stinks, but personally i have no problem with namespace per library.

Of course that requires some mapping from library to package names, and your class name derived tag names sort of indicates that you want to avoid such constructs.

I suppose that some level of metadata is needed anyways, to be able to generate the code that attaches child widgets to parents

/Johannes

@peter: I think we're pretty much on the same page here. The HTMLPanel actually exists in GWT right now, but few use it. It's just a Panel that allows you to easily attach widgets to various sites within statically-specified HTML.

I'm not proposing doing anything more than allowing developers to use existing widgets with a simple markup language. There are a few cases where we'll need "pseudo-elements" -- e.g. <TabPanel> really needs a <Tab> element, even though there's no matching Tab class. But I think this should be the exception rather than the rule.

This will become more clear once I post the first draft prototype, but I believe the way I'm implementing the generator will nudge widget designs in a direction that will make life easier for anyone working on a similar system (e.g. preferring no-arg constructors, encouraging bean-style properties, and so forth). I'm not willing to go so far as to make these explicit restrictions: there are some cases where it's very important to be able to specify immutable values in a constructor (for example), but again this should really be the exception, not the rule.

@J.Alkjaer: I just modified the design with an idea for imports that meshes much better with XML namespaces. The idea is to simply use a urn to identify the gwt module that is to be imported:

<gwt:ui xmlns:gwt='module:com.google.gwt.user.User'>

This allows us to get all widgets from a particular library (module) into a single namespace, and the only possibility of conflict is if you have two instantiable widgets in the same module with the same name. It also gives a pretty natural granularity for the generation of schemae/DTDs.

(I also just noticed that I left a couple of <gwt:import>s in there. Will remove those momentarily)

@gwt.team.jgw - Now that is a truly clever solution ;)

@Joel: good change!

Would this let us move more towards styled divs rather than tables for layout? The 'new table eats font styles' has made our CSS file kinda ugly in spots.

It will certainly make it easier to do so. It's always been possible to do 'css layout' by just shoving everything into a FlowPanel? (which is just a div with children directly attached), but I've not seen this done often, as it's a real pain (for me, anyway) to get simple block-based layouts using CSS.

I'm also hoping to see big gains in efficiency as static structures involving lots of separate panels are converted to simple chunks of HTML with the dynamic bits at the leaves.

jgw - Can you lift the covers on what the requirements of the widgets are for them to be composed/configured declaratively? And more important: is there a "commit" schedule? (i.e. when can we checkout some source code to play around with ourselves ;) /Johannes

@all: I'm moving this wiki page to the incubator, where it probably should have been in the first place.

@j.alkjaer: I'm hoping to check something into the incubator later this week. At the same time, it should become a lot clearer what will be required of widgets, and how you can write custom code to work around widget idiosyncracies.