Skip to main content

Only Desktops??

16 replies [Last post]
aminm
Offline
Joined: 2003-11-14
Points: 0

I was looking at the markup language and squinting to discover why this is limited to a Desktop.

I think it would be highly interesting if the markup would work for web clients as well as "rich clients".

Image you have an app that you sell for a small company (5 to 100 pcs), with distributed features, etc.. using a web interface because of deployment issues. Then you have the same app for smaller companies or individuals without many features that you sell with less support.

Wouldn't it be cool if you could sell a neutered Swing version of your app without changing any code?? This could happen if, among other things, you have a high level markup language (a la JDNC) with which you specify your UIs. Your business layer doesn't care about UIs, neither does that data layer. If you run it one way it renders as an HTML document + Javascript or whatever. If you run it another way it renders as Swing.

I'd be interested in such a thing.. and I'd help with some of the development if necesary. The only condition for this to work is that the markup should be client independent.

Have I misunderstood the potential of this project?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rameshgupta
Offline
Joined: 2004-06-04
Points: 0

> I guess I'm a minority voice. ::)
>
> I don't want to sound thick headed but I think what
> you guys are talking about is not the same as what I
> am talking about.

Actually, I agree with a lot of things you say. This easily is the longest thread on JDNC so far, with spirited discussion on all sides. Happily though, it appears that the participants tend to agree more than disagree :-)

> Certainly, the general UI problem is troublesome if
> you'd like to apply it to a Swing based UI and a
> general Web UI. However, when I write apps, I
> generally have a very limited amount of styles that I
> want to use. [snip] What I am saying is that HOW
> I render the form is one problem, WHAT I want on the
> form is another.
>

You can use a domain-specific language to specify WHAT you want, and leave the HOW part to the interpreter. This is one reason why declarative programming makes people so productive. By lopping off the HOW branch, one only has to worry about half as much as one otherwise would! After that, you just have to worry about choosing the best interpreter -- one that would faithfully render what you specified, perhaps even embellishing the output based on its internal heuristics. If you wanted the output transcoded to HTML, there is no reason, in theory, why this couldn't be done using XSLT or JSF. JDNC does not preclude this approach.

> Therefore, if I wanted a generic UI specifier, I
> would build a renderer (the Swing one and the web
> one) then share the specification of the form. What
> "form" means is up to the renderer. In other words,
> the markup is a domain specific language.. it
> describes "forms" and "dialogs" not widgets.

True, a

could be interpreted as an HTML form or a JDNC form, depending on the targeted user agent.

>
> For a trivial, one could say:
>
>
> > requiredFor="saveType" format="#####" />
>

aminm
Offline
Joined: 2003-11-14
Points: 0

[snip]
> You can use a domain-specific language to specify
> WHAT you want, and leave the HOW part to the
> interpreter. This is one reason why declarative
> programming makes people so productive. By lopping
> off the HOW branch, one only has to worry about half
> as much as one otherwise would! After that, you just

EXACTLY!! You expressed that better than I ever could.

[snip]
> have to worry about choosing the best interpreter --
> one that would faithfully render what you specified,
> perhaps even embellishing the output based on its
> internal heuristics. If you wanted the output
> transcoded to HTML, there is no reason, in theory,
> why this couldn't be done using XSLT or JSF. JDNC
> does not preclude this approach.

Alternatively, you can develop a few standard renderers (Swing, HTML+Javascript, XUL, and dare I say.. SWT?? :).. also renderers could GENERATE code if you like). Then people can be free to customize the renderers as they like given that different companies may wish to impose diferent look and feel standards to their apps..

The idea of a domain specific language is to free that front line developer from details usually.. but please give him easy access to customization to make his app appear a bit different or have a bit new functionality if needed.

Some requirements for the domain language is:
1. Keep it abstracted to its domain (ex: forms only know about form elements not how they are managed once rendered)
2. Extensible.. let me create higher levels of abstraction in a way that is similar to the conventional way of using then (ex: JSP tag files are better than tag libs.. a similar mecanism would be good here)
3. A standard language (ex: JDNC with a better name)

[snip]
> True, a

could be interpreted as an HTML form
> or a JDNC form, depending on the targeted user
> agent.

I would argue that if JDNC works at the level of abstraction of a data driven app (which is what I understood that it is all about) then JDNC is already abstract enough (maybe it could need some repairs). HTML
is one implementation JFrame another.

[snip]
> Well, this is debatable. I agree that in many
> situations, this is good. But the way in which
> interpreters devine the developers' intentions might
> be unpredictable, causing a lot of end-user
> consternation. Think of the early days of the Web
> with incompatible HTML renderers.

You are thinking too low level. The developer intentions are to create a form which contains certain elements that represent certain data elements and the buttons will do certain things (which are defined elsewhere) and certain data is required other is optional, and certain data are search criteria and other is not. This developer should not be concerned AT ALL about rendering.

Rendering is the job of the usability/UI dept... which designs a nice UI on the basis of the description. (More likely, they change a working renderer to do things the way they decide). So if you decide to hide inactive buttons you can do so globally in one place.. you don't have to change each dialog in the app.

> Sometimes, developers need more control that that. A
> simple example is the element type that may
> be used to present a set of mutually exclusive
> choices to the user. Should the interpreter render
> that as a combo box, or as a radio button group? This
> decision cannot be made solely on the basis of the UI
> platform.

Absolutely, the UI renderer decides.. you don't like how it does it.. then change the renderer.. this has nothing to do with the UI description.

[snip]
> This is where stylesheets come in. I think if you
> specified macro-level constructs in the markup, and
> styling hints (e.g., radio button group vs. combo
> box) in a style sheet, then, with suitable
> transcoders, it should be possible to achieve what
> you envision. My suggestion would be to experiment
> with writing simple JSF renderers for a subset of
> JDNC.
>

Interesting.. that might work.

[snip]
>
> Sure, a ?web interface? has certain advantages
> because of deployment issues (This is why JDNC still
> supports applets), but we believe that with Java Web
> Start (and Pack200 compression in J2SE 5.0), web
> deployment of rich Java applications is just as
> easy.

Posibly I'm still attached to the primitive HTML + Javascript solution I currently use.. and I want to easily reuse my code for rich clients.

Maybe JDNC will make HTML + Javascript merge w/ Swing and make the whole point mute.. I guess I have to try that style of deployment and wait for the proper dev tools and documentation to get to that conclusion. But I'll consider it. Hope it is much better that the applet debacle which my customers hated to the point that we just decided to go to HTML + Javascript (others moved to flash).

> The name for the root element ?resource? in JDNC
> markup documents was carefully chosen with the
> Resource Manager feature in mind. The problem is not
> intractable, as eNode and others have successfully
> demonstrated, but it sure is non-trivial to solve,
> especially when you want anything better than the
> greatest common denominator.

Greatest common denominator only exists if you mix abstractions. If I'm talking about forms and reports in data driven apps there is no GCD, because I'm dealing at a much higher level of abstraction than widgets.. :)

rameshgupta
Offline
Joined: 2004-06-04
Points: 0

> [snip]
> > You can use a domain-specific language to specify
> > WHAT you want, and leave the HOW part to the
> > interpreter. This is one reason why declarative
> > programming makes people so productive. By lopping
> > off the HOW branch, one only has to worry about half
> > as much as one otherwise would!
>
> EXACTLY!! You expressed that better than I ever could.
>
> [snip]
> > have to worry about choosing the best interpreter --
> > one that would faithfully render what you specified,
> > perhaps even embellishing the output based on its
> > internal heuristics. If you wanted the output
> > transcoded to HTML, there is no reason, in theory,
> > why this couldn't be done using XSLT or JSF. JDNC
> > does not preclude this approach.
>
> Alternatively, you can develop a few standard
> renderers (Swing, HTML+Javascript, XUL, and dare I
> say.. SWT?? :)..

Bring 'em on!

> also renderers could GENERATE code
> if you like). Then people can be free to customize
> the renderers as they like given that different
> companies may wish to impose diferent look and feel
> standards to their apps..

JDNC is very much a client-side technology. Code-generation and such will put it on a collision course with JSF and other server-side technologies, don't you think?

> [snip]
> > Well, this is debatable. I agree that in many
> > situations, this is good. But the way in which
> > interpreters devine the developers' intentions
> might
> > be unpredictable, causing a lot of end-user
> > consternation. Think of the early days of the Web
> > with incompatible HTML renderers.
>
> You are thinking too low level. The developer
> intentions are to create a form which contains
> certain elements that represent certain data elements
> and the buttons will do certain things (which are
> defined elsewhere) and certain data is required other
> is optional, and certain data are search criteria and
> other is not. This developer should not be concerned
> AT ALL about rendering.

I think we may be saying the same thing in different ways. Or may be not :-) JDNC developers specify things at a sufficiently high level. When using the JDNC markup language, they tell us not only "what" functionality they want (only the "what" part, not the "how" part), but also "what" they want their views to look like. JDNC implementation then figures out "how" the views are realized.

But, in specifying what they want their views to look like, they consult with their usability/UI department (if they are not themselves UI designers, that is).

>
> Rendering is the job of the usability/UI dept...
> which designs a nice UI on the basis of the
> description. (More likely, they change a working
> renderer to do things the way they decide). So if you
> decide to hide inactive buttons you can do so
> globally in one place.. you don't have to change each
> dialog in the app.
>

Rendering, as I understand your usage of the term, involves code generation and/or transformations from one markup language to another -- things that are usually the domain of hard-core developers, not UI/usability experts :-)

>
> > Sometimes, developers need more control that that.
> > A simple example is the element type that
> > may be used to present a set of mutually exclusive
> > choices to the user. Should the interpreter render
> > that as a combo box, or as a radio button group?
> > This decision cannot be made solely on the basis of the
> > UI platform.
>
> Absolutely, the UI renderer decides.. you don't like
> how it does it.. then change the renderer.. this has
> nothing to do with the UI description.

Again, based on my understanding of how you are using the term "renderer", its job is to decide whether to take some markup in a higher-level domain-specific language, and transcode it into HTML, or some other lower-level markup language. So, one renderer could "render" a higher-level element into HTML, and another could "render" the same thing in Swing, right?

If so, the Swing renderer would still need extra information on whether to render a element as a combo box or as a radio button group, and that information *has* to be in the UI description if developers want control over this aspect. Of course, we can use default heuristics when the user/developer has no preference.

[snip]
> >
> > Sure, a ?web interface? has certain advantages
> > because of deployment issues (This is why JDNC still
> > supports applets), but we believe that with Java
> > Web Start (and Pack200 compression in J2SE 5.0),
> > web deployment of rich Java applications is just as
> > easy.
>
> Posibly I'm still attached to the primitive HTML +
> Javascript solution I currently use.. and I want to
> easily reuse my code for rich clients.

HTML+Javascript is, well, primitive. If you are still directly coding things in HTML, there is little hope in reusing that code in rich clients. But if you have a higher-level language that you are transcoding to HTML+JavaScript, the possibility is tantalizing!

>
> Maybe JDNC will make HTML + Javascript merge w/ Swing
> and make the whole point mute.. I guess I have to try
> that style of deployment and wait for the proper dev
> tools and documentation to get to that conclusion.
> But I'll consider it. Hope it is much better that the
> applet debacle which my customers hated to the point
> that we just decided to go to HTML + Javascript
> (others moved to flash).
>
The issue with applets was as much political as technical. Many would blame the applet debacle on Microsoft's refusal to keep up with advances in Java technology.

This is precisely why it is so important to consider Java Web Start for deploying JDNC (or for that matter, any client-side Java application).

Now, developers who moved to HTML+JavaScript years ago, did that because that was the best they could have done under the circumstances. But, a lot of them are finally realizing that they have hit a brick wall, and need to turn around.

I think the same will happen with Flash developers. "Movies" are no way to deliver rich, non-linear, general-purpose user interfaces. Swing and SWT, on the other hand, are.

Ramesh

rameshgupta
Offline
Joined: 2004-06-04
Points: 0

[snip]
> Now back to real products. Most GUI builders try to
> write code which you
> can then modify and it breaks. Sometimes they write
> code and demand you
> don't modify it, which asks the question: "Why write
> the code then!"
> Why create a visual tool which then shoehorns its
> beautiful layout back
> into code. The succesful GUI builders (VB and
> Interface Builder) don't
> write code. They write to a binary format which is
> parsed at runtime to
> generate screens.
>
> Using an XML language gives you the same thing, only
> in a portable
> transparent and (potentially) non-proprietary way.
> Of course there are
> a slew of bad opensource XML layout engines, but
> that's because it's a
> very hard task that still requires a lot of design
> work. And then you
> need it to be standardized to realize the full
> benefits. Hopefully
> that's what JDNC's XML format will do. With Sun's
> stamp of approval I
> hope it will become the standard.

Thank you! You said this better than any of us here could have :-)

>
> As a side bonus, using an XML language for building
> your UI also gives
> you a clean separation of layout from content (giving
> you both spatial
> and temporal division of labor), plus you get a
> simpler language, easier
> debugging, the ability to be used by novices, the
> ability to
> autogenerate, style, or transform it. Lots of nifty
> stuff.

Hear, JDNC Marketing team, please take a note of this :-)

> Now of course we need a good GUI builder that doesn't
> just emulate one
> of the standard layout managers. I've been writing
> such a gui builder
> off and on for about 3 years now, if anyone would
> like to take a look.
> It generates an internal tree structure which is
> currently written out
> to a (bad) set of java classes. I've been meaning to
> write a new export
> plugin to write out JDNC (or at least for the common
> widgets).

You should definitely submit a proof of concept. I am sure if the license is right, people on this forum would be interested in looking at it.

aminm
Offline
Joined: 2003-11-14
Points: 0

> I've thought about the layout problem a lot for the
> past few years (read
> some of my java.net weblog posts for more) and I've
> come to the
> conclusion that the problem with GUI development
> stems from an inherent
> mismatch between the symbolic nature of code and the
> visual nature of
> GUI layout.
>

Java GUI tools are ugly.. they generate CODE!! Yuck!
MS Visual C++ did better than that with resource files.
Keep that declarative stuff out of the code!!!

> Layout is a visual task by nature, and any symbolic
> way of representing
> it would be inferior. Take one page of a magazine,

With the windows resource file format you could almost see your window. There is no way you can see your window
with a Java Swing generated program.

> Using an XML language gives you the same thing, only
> in a portable

I'm not convinced by the XML hype.. but now that it is here I accept it.

...

On the other hand I don't think we should be writing layout code at all.. that is too low level for common tasks. I think we should write some sort of template or renderers for a more abstract representation of our windows and reuse..

I remember back in the day when I did reports with Crystal Reports and Access. All is nice when you layout the components on the screen initially. But what happens when the boss says.. "oh yeah.. change all the titles to red"

For that stupid little change you have to go through 30 reports adjusting the color.. next he says: "now move everything 3 pixels to the left"... aarrrghh

The same happens with dialogs and data entry windows and wizards and help windows and....

Defining a screen and generating the layout should be separate problems.

aminm
Offline
Joined: 2003-11-14
Points: 0

>
> This request comes up a lot - the ability to define
> the UI once and map it both to HTML and rich clients.
> My personal opinion is that it's a bit of a dubious
> s endeavor for all but the most basic HTML-form-like
> client (and even then I'm not sure we'd appreciate
> the end result). When you have all the power of a

I don't understand why this is so intractable. I remember my Windows development days when we used to use a declarative language to specify UI elements in a resource file. You can quickly build up a UI. You only need to specify how to render each Rich control on HTML+Javascript.

That is a fairly straightforward problem. The only remaining issue is to design your forms so that not many round trips are performed between the client and the server. If your windows are like modal dialogs (a common way of designing UIs.. though not the only) this is easy.

> rich client, you'd like a very different division of
> labor between server and client than you get with an
> html app. But that doesn't mean that a large portion
> of an application couldn't be shared across these two
> client types (as well as with mobile), including data
> models, business logic, etc.
>

In the specific example I gave there was no server at all in the rich client version. I'd like to define my app as a web app, then if I'd like, generate a compact, less powerful single-user version where I don't want a webserver, client/server or anything like it.

Joshua Marinacci

I once worked at a company where we shipped a development
platform that used a cross environment markup language for building UIs.
We quickly found that we had to add environment specific hooks to create
anything better than an absolute least common denominator UI. In the
end, any app even close to shipping had so much custom markup for each
target env that you would have been better off just making separate UI
layers for each. We found that the real value in terms of reuse was
reusing the business logic layer. Navigation, graphics, widgets, and
layout all had to be heavily customized for each environment and in the
end it wasn't worth using a cross environment markup.

- Joshua

jdnc-interest@javadesktop.org wrote:

>>This request comes up a lot - the ability to define
>>the UI once and map it both to HTML and rich clients.
>>My personal opinion is that it's a bit of a dubious
>>s endeavor for all but the most basic HTML-form-like
>>client (and even then I'm not sure we'd appreciate
>>the end result). When you have all the power of a
>
>
> I don't understand why this is so intractable. I remember my Windows development days when we used to use a declarative language to specify UI elements in a resource file. You can quickly build up a UI. You only need to specify how to render each Rich control on HTML+Javascript.
>
> That is a fairly straightforward problem. The only remaining issue is to design your forms so that not many round trips are performed between the client and the server. If your windows are like modal dialogs (a common way of designing UIs.. though not the only) this is easy.
>
>
>
>
>>rich client, you'd like a very different division of
>>labor between server and client than you get with an
>>html app. But that doesn't mean that a large portion
>>of an application couldn't be shared across these two
>>client types (as well as with mobile), including data
>>models, business logic, etc.
>>
>
>
> In the specific example I gave there was no server at all in the rich client version. I'd like to define my app as a web app, then if I'd like, generate a compact, less powerful single-user version where I don't want a webserver, client/server or anything like it.
> ---
> [Message sent by forum member 'aminm' (dog)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=13131&#13131
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

gweedo
Offline
Joined: 2003-06-12
Points: 0

I couldn't agree with you more Joshua. I've seen the same pattern repeated several times. It is one of those things that sounds really good on "paper", but really falls short when put into practice. About the best implementation of this I've seen is done by Apple in their WebObjects product. But while very slick, it still ends up falling short. I'm convinced that there isn't a happy medium between a web client and a rich client. Just focus on them as separate presentation mediums, understanding that each has their own requirements and limitations.

This reminds me of the many xml gui layout projects. Just say no. :)

rbair
Offline
Joined: 2003-07-08
Points: 0

I agree in every respect except for...

> This reminds me of the many xml gui layout projects.
> Just say no. :)

There is at least one very compelling reason for an XML layout file for the gui: gui builders. GuiBuilders work so much better with modifying a descriptor file rather than modifying code. It is terribly complex to try to write a gui builder that is 100% capable of reading arbitrary source code to show in the gui and then modifying that source code without totally trashing it. I'd even say its so difficult as to be impossible in practice.

And even if you take the NetBeans approach and put a certain method or two "out of bounds", you still end up with code that is in every case I've explored inefficient (does anybody else remember JBuilder's panel.add(myComponent, new GridBagConstraints...) code? A lot of object creation for no good reason).

And then gui builders always expose every component as either a public or package protected variable -- talk about a waste! In most gui's (especially with data binding) you only need to have a handful of components (usually 3-5) exposed -- and that's just for event handling (buttons and the like).

But I agree that gui's are not something that you can leave up to a piece of code to generate if you want it to look good, contrary to what some opine. You really need a flesh and blood designer laying out windows etc.

gweedo
Offline
Joined: 2003-06-12
Points: 0

> I agree in every respect except for...
>
> > This reminds me of the many xml gui layout projects.
> > Just say no. :)
>
> There is at least one very compelling reason for an
> XML layout file for the gui: gui builders.[...]

If a gui builder decides to save all it's layout stuff in XML, that is fine by me. :-) I think I was objecting to Java gui builders in general. At least the ones I have encountered thus far. I understand the need, I even wish there was a good one. I just don't anticipate seeing a good one any time soon.

Here is my take on why...

From the early examples in Swing, the common approach has been to subclass JFrame, JPanel, etc. just to layout things. This is fundamentally a [b]really[/b] bad practice imho. You don't subclass JButton to change it's label, you should't subclass JFrame just to layout it's contents. But, that is what 99.9% of the Java developers are out there doing. And they are doing that because all the books, examples, etc. tell them to. Ack! That makes putting together a clean gui builder that much harder for Java. You don't have developers hooking up a fairly stable set of gui components to business logic. MVC who? Instead gui builders have to contend with this big hairball. Subclassing a gui component should be the exception, not the norm me thinks.

I'll spare you, and cut my rant short... :-) I guess having a NeXT background corrupted my thinking.

Joshua Marinacci

I've thought about the layout problem a lot for the past few years (read
some of my java.net weblog posts for more) and I've come to the
conclusion that the problem with GUI development stems from an inherent
mismatch between the symbolic nature of code and the visual nature of
GUI layout.

Layout is a visual task by nature, and any symbolic way of representing
it would be inferior. Take one page of a magazine, describe it using
english in, lets say 1000 words. Then hand your essay to someone else
and have them redraw it. It's not going to look the same. It's a visual
task. Code is bad at doing layout.

On the flipside, GUI builders write horrid horrid code because they are
visual tools trying to do what is an inherently symbolic task. That's
why no visual programming language has ever worked. It's just too
different worlds.

Now back to real products. Most GUI builders try to write code which you
can then modify and it breaks. Sometimes they write code and demand you
don't modify it, which asks the question: "Why write the code then!"
Why create a visual tool which then shoehorns its beautiful layout back
into code. The succesful GUI builders (VB and Interface Builder) don't
write code. They write to a binary format which is parsed at runtime to
generate screens.

Using an XML language gives you the same thing, only in a portable
transparent and (potentially) non-proprietary way. Of course there are
a slew of bad opensource XML layout engines, but that's because it's a
very hard task that still requires a lot of design work. And then you
need it to be standardized to realize the full benefits. Hopefully
that's what JDNC's XML format will do. With Sun's stamp of approval I
hope it will become the standard.

As a side bonus, using an XML language for building your UI also gives
you a clean separation of layout from content (giving you both spatial
and temporal division of labor), plus you get a simpler language, easier
debugging, the ability to be used by novices, the ability to
autogenerate, style, or transform it. Lots of nifty stuff. But this core
is that it makes GUI builders possible.

Now of course we need a good GUI builder that doesn't just emulate one
of the standard layout managers. I've been writing such a gui builder
off and on for about 3 years now, if anyone would like to take a look.
It generates an internal tree structure which is currently written out
to a (bad) set of java classes. I've been meaning to write a new export
plugin to write out JDNC (or at least for the common widgets). In my
spare time, of course. :)

- J

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

pierrem
Offline
Joined: 2004-06-24
Points: 0

Hi, you said:
========================
"Using an XML language gives you the same thing, only in a portable
transparent and (potentially) non-proprietary way. Of course there are
a slew of bad opensource XML layout engines, but that's because it's a
very hard task that still requires a lot of design work. And then you
need it to be standardized to realize the full benefits. Hopefully
that's what JDNC's XML format will do. With Sun's stamp of approval I
hope it will become the standard."
=====================

I will push a product I am working on for a while. We do exactly what you are talking.

UI design in XML, no need to be a programmer
Coding in Java and/or 10 scriptings language for the business logic
Localization done by the UI designer
JavaHelp system with context sensitivity done by the UI Designer
User preferences save/retrieve done by the UI designer
Adding of new tags/components (as an example, we have wrap the Batik SVGCanvas as a tag to display SVG file)
Let the UIDesigner code the UI in his/her mother tongue
Zero deployment of the UI.

Take a look at a step by step tutorial.
Select Get Started - Quick tour
www.ultrid.com

aminm
Offline
Joined: 2003-11-14
Points: 0

I guess I'm a minority voice. ::)

I don't want to sound thick headed but I think what you guys are talking about is not the same as what I am talking about.

Certainly, the general UI problem is troublesome if you'd like to apply it to a Swing based UI and a general Web UI. However, when I write apps, I generally have a very limited amount of styles that I want to use. For example, the dialogs follow some look and feel, the CRUD forms have a certain criteria they follow as well. The difference between a web implementation and a Swing implementation should be handled by the renderer. What I am saying is that HOW I render the form is one problem, WHAT I want on the form is another.

Therefore, if I wanted a generic UI specifier, I would build a renderer (the Swing one and the web one) then share the specification of the form. What "form" means is up to the renderer. In other words, the markup is a domain specific language.. it describes "forms" and "dialogs" not widgets.

For a trivial, one could say:

requiredFor="saveType" format="#####" />
Joshua Marinacci

Ah, I see. If your task is domain specific than this would certainly be
a good idea. I think some people have written a few toolkits to do this.
Essentially you want basic layout, data binding, and field validation
written into an XML file, which is then rendered on the fly to the
requested device. As long as you stay within the domain it should be
quite doable.

- Joshua
jdnc-interest@javadesktop.org wrote:

> I guess I'm a minority voice. ::)
>
> I don't want to sound thick headed but I think what you guys are
> talking about is not the same as what I am talking about.
>
> Certainly, the general UI problem is troublesome if you'd like to
> apply it to a Swing based UI and a general Web UI. However, when I
> write apps, I generally have a very limited amount of styles that I
> want to use. For example, the dialogs follow some look and feel, the
> CRUD forms have a certain criteria they follow as well. The
> difference between a web implementation and a Swing implementation
> should be handled by the renderer. What I am saying is that HOW I
> render the form is one problem, WHAT I want on the form is another.
>
> Therefore, if I wanted a generic UI specifier, I would build a
> renderer (the Swing one and the web one) then share the specification
> of the form. What "form" means is up to the renderer. In other words,
> the markup is a domain specific language.. it describes "forms" and
> "dialogs" not widgets.
>
> For a trivial, one could say:
>
>

> format="#####" />
Anonymous

This deserves a longer discussion, but JavaOne is distracting us at the moment, so I'll make just a few comments now.

This request comes up a lot - the ability to define the UI once and map it both to HTML and rich clients. My personal opinion is that it's a bit of a dubious endeavor for all but the most basic HTML-form-like client (and even then I'm not sure we'd appreciate the end result). When you have all the power of a rich client, you'd like a very different division of labor between server and client than you get with an html app. But that doesn't mean that a large portion of an application couldn't be shared across these two client types (as well as with mobile), including data models, business logic, etc.

Putting my skepticism aside, we could explore using a technology like JSF to bridge these two options for cases where what you want in the rich client is limited to a more interactive form. We could write JSF renderers that generate JDNC markup instead of HTML.

Gregg Wonderly

jdnc-interest@javadesktop.org wrote:
> Putting my skepticism aside, we could explore using a technology like JSF to bridge
> these two options for cases where what you want in the rich client is
limited to a more
> interactive form. We could write JSF renderers
> that generate JDNC markup instead of HTML.

Exploiting mobile code in Java is a great way to have the correct UI for
the correct situation. The Jini ServiceUI mechanism lets a service
advertise all the possible UIs that it provides. This means that you
could have a UI Role of 'webpage' that might actually be an HTML
renderer that did what was needed to support a web based user. A JSP or
other servlet like interface would lookup this service, grab the correct
UI, and then mediate between the clients HTML based requests and the
service.

Gregg Wonderly

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net