Skip to main content

JNForm is useless!

21 replies [Last post]
kxmas
Offline
Joined: 2004-07-28

It is impossible to use another JForm with the JNForm and therefore impossible to change to default submit action. What's worse is that form is a private member of JNForm so I can't even extend it to get the behavior that I want.

If there is another way to change the submit action, please let me know. I'm stumped.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
dhall
Offline
Joined: 2006-02-17

>> There seems to be a lot of desire for such a component. I've just filed Issue 39 https://jdnc.dev.java.net/issues/show_bug.cgi?id=39) which describes this feature. Please add your requirements and ideas to this issue. The next step would be to take these comments and consolidate them into a specific design proposal.

(Can we modify something on that page? I wonder if it might be better if we gather the requirements elsewhere and let that page describe the group decision)

There's a couple of different layout strategies for potential uses of a button panel component. It seems like most Wizards have the buttons clustered toward the right, while most other types of dialogs have the button panel spread out across the bottom. Also, I know that I've seen dialogs where there were two such collections of buttons: one main list of buttons across the button containing ok, cancel, help, and another vertical button bar containing controls that effect changes in the dialog but don't close it.

dhall
Offline
Joined: 2006-02-17

oh, and BTW

+1 for the addition of a ButtonPanel component, whatever its prefix turns out to be.

Mark Davidson

On 07/23/2004 10:39 AM, Amy Fowler wrote:
> Or, maybe we should add a JXButtonPanel component -- I know I've spent
> untold hours trying to get the layout of the buttons looking right in
> dialogs/frames, and such a component could handle the look&feel
> differences. It would make it so much easier to create consistent
> looking forms/dialogs. JNForm could use it, but it would also provide
> support for those who want to use their own panels to create forms.
>
> We could also add the JNForm API above for convenience of course.
> Best of both worlds. Anyone in favor, send your "+1".

+1

There seems to be a lot of desire for such a component. I've just filed
Issue 39 (https://jdnc.dev.java.net/issues/show_bug.cgi?id=39) which
describes this feature. Please add your requirements and ideas to this
issue. The next step would be to take these comments and consolidate
them into a specific design proposal.

--Mark

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

James Todd

hey -

i'm looking for, among other things, a "preferences" high-order widget,
like that of mozilla "edit/prefs" ... which is really just a JTree and
a corresponding panel relative to the selected tree element.

easy enough i suspect but given that i'd like to take a swing through
some ui code and will introduce jdnc in places i'd like to query about
this one as well.

suggestions?

much appreciated,

- james

--
Java == platform independence
XML == application independence
JXTA == network independence

Secure End-to-End Computing

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

Sundaranathan Sivashanmuganthan

+1

-Sundar.

Amy Fowler wrote:

> jdnc-interest@javadesktop.org wrote:
>
>>>
>>> The way I see it working:
>>>
>>> form.setButtonPanel(
>>> actionContainerFactory.createButtonPanel(actionList));
>>
>>
>>
>> Yes, I agree that we should simplify this. But I have slight
>> reservations about adding a createButtonPanel method to
>> ActionContainerFactory, primarily because (unlike MenuBar and
>> ToolBar) ButtonPanel is not a standard Swing or JDNC component.
>>
>> What do you think about form.addAction(actionList) and
>> form.setAction(actionList) instead? Internally, we could use
>> JNForm.createButtonPanel without having to define a new
>> ActionContainerFactory.createButtonPanel method.
>
>
> Or, maybe we should add a JXButtonPanel component -- I know I've spent
> untold hours trying to get the layout of the buttons looking right in
> dialogs/frames, and such a component could handle the look&feel
> differences. It would make it so much easier to create consistent
> looking forms/dialogs. JNForm could use it, but it would also provide
> support for those who want to use their own panels to create forms.
>
> We could also add the JNForm API above for convenience of course.
> Best of both worlds. Anyone in favor, send your "+1".
>
> Aim
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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

kxmas
Offline
Joined: 2004-07-28

+1

Adrian Sutton

> Or, maybe we should add a JXButtonPanel component -- I know I've spent
> untold hours trying to get the layout of the buttons looking right in
> dialogs/frames, and such a component could handle the look&feel
> differences. It would make it so much easier to create consistent
> looking forms/dialogs. JNForm could use it, but it would also provide
> support for those who want to use their own panels to create forms.

Absolutely, it would save a lot of code that switches the order of
buttons around on OS X thus making Java apps fit into the OS that much
better. It would also be able to handle changing the order correctly
for arabic systems etc.

One other requirement is that the buttons are the same size in the
panel. For instance, cancel buttons by default are wider than OK
buttons but in well-designed apps they should be the same size. On Mac
there's specific sizes that buttons should be whenever possible as
well.

> We could also add the JNForm API above for convenience of course.
> Best of both worlds. Anyone in favor, send your "+1".

+1

> Aim

Regards,

Adrian Sutton.

----------------------------------------------
Intencha "tomorrow's technology today"
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com
[PGP.sig]

dcurry
Offline
Joined: 2006-02-17

> Or, maybe we should add a JXButtonPanel component --
> [snip]
> We could also add the JNForm API above for
> convenience of course.
> Best of both worlds. Anyone in favor, send your
> "+1".

+1 - "A" answer!

Marc Logemann

Hi,

i saw that JDNC supports Filtering of JTable data out of the box. I have
not covered yet if this filtering input will be exposed to the UI. For
instance, when i want to filter a specific column with value "myFilter",
will there be some JTable integrated way to specify the value?

See the attached GIF of my current approach to handle this. Its not as
pretty as it want to, but i dont know too many other spots where one
should plug this in. RIght now, when i want to sort fields, i click
left, then every column looks like a standard tableheader column, when i
right click on a column, the header gets expanded to accomodate the
height and the shown label/textField box is displayed.

What is the JDNC way to handle this? Of course you can create an extra
panel with a filter textField, but this wouldnt be very integrated.
How does JDNC handle this? Perhaps i can switch over to some JDNC
components...

--
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de
[table.gif]
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

dcurry
Offline
Joined: 2006-02-17

> Yes, I agree that we should simplify this. But I have
> slight reservations about adding a createButtonPanel
> method to ActionContainerFactory, primarily because
> (unlike MenuBar and ToolBar) ButtonPanel is not a
> standard Swing or JDNC component.
>
I remember when ToolBars weren't standard components either. Everybody had lots of fun coding our own implementations -- all of which died out when Borland and Microsoft introduced the standard components in OWL and MFC.

As I understand it, part of Sun's motivation for open-sourcing JDNC is to get developer feedback on its evolution. ButtonPanel may not be a standard component today, but through this kind of forum we might make it one.

kxmas
Offline
Joined: 2004-07-28

> Additionally, I've been thinking lately that while
> it's fine to have
> the JForm/JNForm components to make it very easy to
> quickly create
> forms, much of the form processing functionality
> should be upleveled
> so that it can be used independent of these Form
> components. This
> is why I placed the binding API outside of the form
> package, but there
> is more to it than that. One should be able to use
> the
> binding/groups/validation/form-action functionality
> with their own
> garden variety panels. I'm going to investigate
> leveraging Karsten's
> JGoodies binding & validation frameworks with this in
> mind.
>
> I've gone back and forth on whether the form
> 'behavior' should be
> encapsulated as named actions (as it is now) or as an
> explicit
> listener interface. I'm still leaning towards
> actions (an action being
> a 'generic' listener), but would like to know what
> developers would
> rather see. The "reset" and "revert" behaviors can
> be handled in a
> standard way by the binding framework and apps
> shouldn't need to
> customize those behaviors too often. But the
> "submit" behavior will
> almost always need to be customized by the
> application. Would it be
> easier for applications to extend a default submit
> action or register
> an explicit FormListener which has a formSubmitted()
> method? (this
> method would be called AFTER the values have been
> pushed to the model)
>
> While we re-think the form/binding architecture, I
> can at least
> make some simple changes in the current API to meet
> your needs.
> Please file a bug on this issue to ensure I get to
> fixing it soon!
>
> Aim

I'm thinking along the same lines as the others that I replied.

I'd probably like to see a method called addAction that takes a command name and an action object. The method would add a button with a label of the command name. Convience methods for adding a submit, reset, and revert would be helpful too.

In my mind, the functionality of a form is pretty well defined so I don't see a great benefit of adding a listener interface.

Thanks for your help.

Kevin

dcurry
Offline
Joined: 2006-02-17

I would prefer to see a simple way to create a button panel from a list of Actions and attach it to a JNForm. This could be modeled after ActionContainerFactory.createMenuBar().

The way I see it working:

form.setButtonPanel(actionContainerFactory.createButtonPanel(actionList));

This would allow JDNC to establish default Actions in JNForm where they make sense (for example, Reset) without forcing the programmer to expose them on every form.

I agree that there can be no reasonable default for the Submit action. As long as it's easy to define a button on the panel and attach it to an action, this won't matter.

The advantage to using Actions is that it would allow the same behavior to be easily attached to a menu item, a toolbar icon, and a form button -- all of which share the same label, icon, mnemonic and accelerator.

Productivity through simplicity. Having learned how Actions work, the programmer should be able to use them anywhere a user interaction triggers an application behavior.

rameshgupta
Offline
Joined: 2004-06-04

> I would prefer to see a simple way to create a button
> panel from a list of Actions and attach it to a
> JNForm. This could be modeled after
> ActionContainerFactory.createMenuBar().
>
> The way I see it working:
>
> form.setButtonPanel(
> actionContainerFactory.createButtonPanel(actionList));

Yes, I agree that we should simplify this. But I have slight reservations about adding a createButtonPanel method to ActionContainerFactory, primarily because (unlike MenuBar and ToolBar) ButtonPanel is not a standard Swing or JDNC component.

What do you think about form.addAction(actionList) and form.setAction(actionList) instead? Internally, we could use JNForm.createButtonPanel without having to define a new ActionContainerFactory.createButtonPanel method.

Ramesh

Amy Fowler

jdnc-interest@javadesktop.org wrote:

>>
>>The way I see it working:
>>
>>form.setButtonPanel(
>>actionContainerFactory.createButtonPanel(actionList));
>
>
> Yes, I agree that we should simplify this. But I have slight reservations about adding a createButtonPanel method to ActionContainerFactory, primarily because (unlike MenuBar and ToolBar) ButtonPanel is not a standard Swing or JDNC component.
>
> What do you think about form.addAction(actionList) and form.setAction(actionList) instead? Internally, we could use JNForm.createButtonPanel without having to define a new ActionContainerFactory.createButtonPanel method.

Or, maybe we should add a JXButtonPanel component -- I know I've spent
untold hours trying to get the layout of the buttons looking right in
dialogs/frames, and such a component could handle the look&feel
differences. It would make it so much easier to create consistent
looking forms/dialogs. JNForm could use it, but it would also provide
support for those who want to use their own panels to create forms.

We could also add the JNForm API above for convenience of course.
Best of both worlds. Anyone in favor, send your "+1".

Aim

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

Patrick Wright

+1

Check out JGoodies Forms--he has a factory for creating sets of commonly
used buttons as an example (OK, Cancel; OK Cancel Apply, etc.). I think it
is useful...look this can just be a factory which returns Panels. One
problem with Swing is how many lines of code it takes to do something
reasonable...this seems like a good idea.

Patrick

> jdnc-interest@javadesktop.org wrote:
>
>>>
>>>The way I see it working:
>>>
>>>form.setButtonPanel(
>>>actionContainerFactory.createButtonPanel(actionList));
>>
>>
>> Yes, I agree that we should simplify this. But I have slight
>> reservations about adding a createButtonPanel method to
>> ActionContainerFactory, primarily because (unlike MenuBar and ToolBar)
>> ButtonPanel is not a standard Swing or JDNC component.
>>
>> What do you think about form.addAction(actionList) and
>> form.setAction(actionList) instead? Internally, we could use
>> JNForm.createButtonPanel without having to define a new
>> ActionContainerFactory.createButtonPanel method.
>
> Or, maybe we should add a JXButtonPanel component -- I know I've spent
> untold hours trying to get the layout of the buttons looking right in
> dialogs/frames, and such a component could handle the look&feel
> differences. It would make it so much easier to create consistent
> looking forms/dialogs. JNForm could use it, but it would also provide
> support for those who want to use their own panels to create forms.
>
> We could also add the JNForm API above for convenience of course.
> Best of both worlds. Anyone in favor, send your "+1".
>
> Aim
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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

Gregg Wonderly

Please look at the packer.dev.java.net project for a simple to use table
based layout. Also, look at swingutil.dev.java.net and see if there are
any useful classes there. These are projects that I created from code
I've been using for some time. If they look useful to you, they are
there for the taking.

Gregg Wonderly

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

Amy Fowler

Gregg Wonderly wrote:

> Please look at the packer.dev.java.net project for a simple to use table
> based layout. Also, look at swingutil.dev.java.net and see if there are
> any useful classes there. These are projects that I created from code
> I've been using for some time. If they look useful to you, they are
> there for the taking.

A number of people at J1 pointed me to packer and I'm anxious to take
a look. Can you characterize the sorts of functionality in the swingutil
project? We'll also be looking at JGoodies to see about leveraging
Karsten's good work there.

There are 2 possible tricky issues with adding dependencies on external
libraries:

1) licensing -- the 3rd party license must be compatible with our LGPL
license (i'll stop there, being a relative newcomer to the open source
licensing scene)

2) if the library is large, but we only want/need a subset, then we may
be reticent to build in such a dependency

Though I suspect neither of these are issues with packer or swingutil. ?

Aim

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

dcurry
Offline
Joined: 2006-02-17

.

Amy Fowler

jdnc-interest@javadesktop.org wrote:

> It is impossible to use another JForm with the JNForm and therefore impossible to change to default submit action. What's worse is that form is a private member of JNForm so I can't even extend it to get the behavior that I want.
>
> If there is another way to change the submit action, please let me know. I'm stumped.

We have much work to do on JForm/JNForm. One of the current glaring
holes is lack of easy way to hook in your own handling for "Submit",
"Revert", and "Reset" actions.

Additionally, I've been thinking lately that while it's fine to have
the JForm/JNForm components to make it very easy to quickly create
forms, much of the form processing functionality should be upleveled
so that it can be used independent of these Form components. This
is why I placed the binding API outside of the form package, but there
is more to it than that. One should be able to use the
binding/groups/validation/form-action functionality with their own
garden variety panels. I'm going to investigate leveraging Karsten's
JGoodies binding & validation frameworks with this in mind.

I've gone back and forth on whether the form 'behavior' should be
encapsulated as named actions (as it is now) or as an explicit
listener interface. I'm still leaning towards actions (an action being
a 'generic' listener), but would like to know what developers would
rather see. The "reset" and "revert" behaviors can be handled in a
standard way by the binding framework and apps shouldn't need to
customize those behaviors too often. But the "submit" behavior will
almost always need to be customized by the application. Would it be
easier for applications to extend a default submit action or register
an explicit FormListener which has a formSubmitted() method? (this
method would be called AFTER the values have been pushed to the model)

While we re-think the form/binding architecture, I can at least
make some simple changes in the current API to meet your needs.
Please file a bug on this issue to ensure I get to fixing it soon!

Aim

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

Tom Ball

On Wed, 2004-07-21 at 11:14, Amy Fowler wrote:
> I've gone back and forth on whether the form 'behavior' should be
> encapsulated as named actions (as it is now) or as an explicit
> listener interface. I'm still leaning towards actions (an action being
> a 'generic' listener), but would like to know what developers would
> rather see. The "reset" and "revert" behaviors can be handled in a
> standard way by the binding framework and apps shouldn't need to
> customize those behaviors too often. But the "submit" behavior will
> almost always need to be customized by the application. Would it be
> easier for applications to extend a default submit action or register
> an explicit FormListener which has a formSubmitted() method? (this
> method would be called AFTER the values have been pushed to the model)

This may not be relevant, but last year I rewrote the libglade support
in Java-GNOME, which is the library that connects an XML UI description
file created by Glade to Java application code.

Since GTK widgets (like Swing components) can fire a number of different
events, a developer creates an "event listener" by selecting the
component in Glade, selecting which signal (event), then specifying the
procedure name (or Java method name) to call and any parameters. At
application startup, the libglade runtime creates and registers
listeners which invoke the specified procedure when an event is fired.

>From this experience, it seems like it would be easier for tools if you
supported registration of a FormListener, rather than extending a
default action. It's fine to have default actions where appropriate,
although as you point out there isn't a good default for Submit. If
these defaults can be replaced instead of extended then the form and the
application code are not so tightly bound together.

Tom

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

Anonymous

Welcome, Tom!
(Tom and I go way back to ancient Java days :-)

[snip]
>
> This may not be relevant, but last year I rewrote the
> libglade support
> in Java-GNOME, which is the library that connects an
> XML UI description
> file created by Glade to Java application code.
>
> Since GTK widgets (like Swing components) can fire a
> number of different
> events, a developer creates an "event listener" by
> selecting the
> component in Glade, selecting which signal (event),
> then specifying the
> procedure name (or Java method name) to call and any
> parameters. At
> application startup, the libglade runtime creates and
> registers
> listeners which invoke the specified procedure when
> an event is fired.

We've been pondering the different ways one might hook application behavior to the xml form description and certainly this stubs approach is one to consider because we can hide the listener glue (via dynamic proxy) which binds an event to the named method in application stubs file. I want to work with the tools folks to understand what structure they would like to see for this separation of behavior from the view, but the fact that Glade (and others) tend to promote this style is an indication it would be a good way to go.

>
> >From this experience, it seems like it would be
> easier for tools if you
> supported registration of a FormListener, rather than
> extending a
> default action. It's fine to have default actions
> where appropriate,
> although as you point out there isn't a good default
> for Submit. If
> these defaults can be replaced instead of extended
> then the form and the
> application code are not so tightly bound together.

There's a good rationale. I also think it makes the API more explicit and perhaps easier to "get" just by looking at it.