In the form widget something similar to what you describe exists.
After the field elements you can have a sort-order element which has a
sort-field element in it for each field in the order you want it.
Those sort-field elements can be put inside a field-group element, and
the field-group element has the typical id and style attributes on it
for CSS styling of a group of fields.
There are no conditions on the group, as conditions are on the
individual fields right now, but we could add something as simple as a
use-when attribute there or as complex as a condition element with the
various conditional sub-elements under it like in a screen widget
section. Unless we think those will be used a lot I like the idea of
the use-when attribute more, BTW.
-David
On Jun 6, 2008, at 8:42 AM, Adrian Crum wrote:
I've been thinking about this and I'm wondering if we need a
container element for the form and menu widgets, only have it
operate more like the section element - so you can have conditionals.
That way you could group fields or menu items together, have the
group displayed conditionally, and have them wrapped by the
rendering classes so they can be updated by Ajax calls.
-Adrian
Anil Patel wrote:
thinking on same lines, We should have a set of input boxes that
get rendered to meet formating requirements, like
For phone number, I'll like to have a form widget that will render
countryCode, areaCode, contactNumber input boxes in one row
separated by some character like "-". Similarly Date field may be
required to be rendered in some cases. Or Credit Card numbers etc.
Regards
Anil Patel
On Jun 3, 2008, at 5:07 AM, Jacopo Cappellato wrote:
Here is my wish list:
1) when you select a value from a drop down box, automatically
enable a new drop down box for the selection of further data
available after the first selection is done; for example: you
select the country, then you have the option to select the state-
province in the country
2) when, using a lookup button you select an id (e.g. productId)
another field (or label) is automatically populated with the
descriptive content of the id (productName etc...)
Jacopo
On Jun 3, 2008, at 3:35 AM, Anil Patel wrote:
I think we should Ajax/Effects enable widgets where possible. Like,
Make Panels collapsable using Effects,
Ajax enable Tree widget,
Enhance Single form Layout to use div and css,
Use Model panel for Lookup windows,
Allow display fields to be inline editable etc.
Regards
Anil Patel
On Jun 2, 2008, at 6:11 PM, Jacques Le Roux wrote:
From: "Adrian Crum" <[EMAIL PROTECTED]>
Al Byers wrote:
I started a post to your reply that talked about what I would
like to see
and whatever, but as I got into it, I realized that this whole
thing could
get quite messy. As soon as you do anything that is "customer
facing", I
think you are going to lose people (like me) because what we
do with widgets
could never approach what their specific toolkit can do.
Well, the discussion is about adding Ajax capabilities to the
screen widgets - which aren't usually used in customer facing
websites.
I picture this effort as something simpler than the type of
work you described. Let's add some bells and whistles to the
screen widgets. The screen widget XML to do it shouldn't be
overly complicated. In other words, add some fancy
embellishments without a lot of extra coding.
I just think the work of trying to add some common features
that can be
supported by all tool kits will not be useful because it will
never go far
enough. And it will be a lot of work that will not add much
advantage over
just working in the toolkit (this is particularly true of Dojo
since it has
an XML markup language that lets me mix it with the widget
environment
within .ftl files.)
There has been talk of doing that with Dojo and another XML
based library (I can't remember the name - Jacopo mentioned it).
I suppose you tall about Apache XAP ?
Jacques
Thanks for the reply - I appreciate your input!
-Adrian
