I'm thinking that the fields will be contained in a list or fieldset
and a hyperlink will cause a new field to be appended. Each appended
widget would be identical to the others with the name/id incremented.
because it would make validation easier. When I did it there was no
RepeatingWidget (and this was one of the motivations that led Michele and
Alberto to implement that kind of widget)...
What I see from a fast look at the docs is that unfortunately you have to pass
the number of repetitions at the declaration time. If you pass it on
instantiation, then the form won't know how many copies it should validate
(I'm talking about using it on the decorator, one might put it on the code and
set tg_errors... hmmmm).
Then, you'd use soma AJAJ for inserting a new instance of your form / fieldset
/ fields into the screen. It shouldn't be hard (validating on the body of the
function you'll know how many instances to process).
Jorge Godoy <jgo...@gmail.com>
I would appreciate any feedback and I'll keep it available for a few
Looks very good. A few suggestions:
- focus & select the first field when adding a field set.
- you should be able to remove any field set, not just the last one.
- add the event handlers for the "Add"/"Remove" links with MochiKit's "connect"
function. This allows to add other handlers later, if necessary.
- put the "Add"/"Remove" links on a separate <li> item, this makes styling easier.
BTW, where did you get the TG logo and header from? I was searching the TG site
recently for better logos than the ones in 1.0b distro and could not them.
There should be a "branding/marketing" section on the TG website!
Why the first field? Would it make more sense to select the one just
added? Or do you mean the first of the set just added?
> - you should be able to remove any field set, not just the last one.
> - add the event handlers for the "Add"/"Remove" links with MochiKit's "connect"
> function. This allows to add other handlers later, if necessary.
I'll have to look into this because I haven't used MochiKit's connect
> - put the "Add"/"Remove" links on a separate <li> item, this makes styling easier.
> BTW, where did you get the TG logo and header from? I was searching the TG site
> recently for better logos than the ones in 1.0b distro and could not them.
> There should be a "branding/marketing" section on the TG website!
It was the default on a quickstarted 1.0b app.
Thanks for the feedback Chris.
>> - you should be able to remove any field set, not just the last one.
>> - add the event handlers for the "Add"/"Remove" links with MochiKit's "connect"
>> function. This allows to add other handlers later, if necessary.
> I'll have to look into this because I haven't used MochiKit's connect
> function before.
connect(element or 'element_id', 'onsomething', function);
/* passes form as element, not as element ID */
/* or just change 'addItem()' to accept an event object instead of an element ID */
>> BTW, where did you get the TG logo and header from? I was searching the TG site
>> recently for better logos than the ones in 1.0b distro and could not them.
>> There should be a "branding/marketing" section on the TG website!
> It was the default on a quickstarted 1.0b app.
Ups, I must have used the "static" directory from an old quickstarted app. The
strange thing is, my TG installation still only contains the old pictures in
its static directory!? I will try to do a clean install again, and see what
He meant the first field of the added set.
As for the rest, I use this pattern quite a bit (I call it an
InputList), though I haven't used it on a TG widget form yet. If you
put the code somewhere I can grab it, I'll do the styling and
structural change I'd prefer is that the form fields contained in <div>
elements be contained in <ul><li> instead because they're more flexible
with CSS. For example, they could be displayed vertically or
horizonally and with or without bullets.
I haven't started dealing with widgets yet, but it's nice to see what
can be done.
- When you add a new field set, the fields are always filled in with the values
from the first field set. I would either leave them empty or fill in the values
from the bottommost field set.
- The "Add" link ist still not properly embedded in the <ul> list of the form.
Yes. They should be empty.
> - The "Add" link ist still not properly embedded in the <ul> list of the form.
I don't understand why this would be a good thing. Currently, the <ul>
list is a list of form field sets. A new form field set is simply
appended to the list. Adding the link to the list would break the
pattern. For specific styling it could be given a class name. I'm not
saying I couldn't be convinced, just that I don't yet see the advantage
of doing it.
Or you could add another link next to each field set labelled "Clone" that
would put a copy of the field set at the bottom of the list (or just below the
item). Just an idea, dunno if this is really useful.
>> - The "Add" link ist still not properly embedded in the <ul> list of the form.
> I don't understand why this would be a good thing.
It's just not proper HTML, IMO. But it's just a minor point.
> Currently, the <ul> list is a list of form field sets.
No, I mean the outer <UL> list.
This is how I would structure the code:
<LI CLASS="appendablefieldset" ID="fieldset_0">
<INPUT ... />
<INPUT ... />
<INPUT TYPE="submit" CLASS="submitbutton">
I'm curious as to why you think it's not proper html. It will
valildate as XHTML Strict though my examples are published as HTML 4.
I'll publish the next example as XHTML Strict.
One big issue I haven't addressed yet. After the form has been
submitted, trips back to the form must recreate the extra form fields
based on how much data was submitted originally. Examples include
displaying validation errors and editing form data.
The feedback has been great. I've included a copy of the entire
quickstarted project if you'd like it.
If you do check it out, post a note here about your impressions.
> Randall wrote:
>> Do you think it would be acceptable for this to be an understood
>> limitation for this widget? The other scenarious (prepopulate on edit,
>> etc.) are addressable on the server side and I've already got a good
>> idea how to do it.
> Don't see any option, really. It's an existing limitation for many AJAX
> applications, and nobody seems to be screaming. I've never liked the
> "back" button anyway :-)
There are some non-portable options¹ but your code gets ugly or your location
bar gets ugly. And you have to code specifically for that.
I won't worry with the back button with this kind of setup. One thing to
think is "why would the user hit the back button?" and then try to provide
alternative means to get there. Most users will click on an hyperlink saying
"Previous Page" instead of the back button and then you could attach some
you're populating these with data from the database, then it's just a matter
of reading them again.
Jorge Godoy <jgo...@gmail.com>
I would appreciate it if someone tested this on IE. I've only got
Mozilla and Safari.
Error: 'label.getAttribute(...)' is null or not an object
(translated from German)
BTW, If you were using Linux, I'd recommend you have a look at this:
But shouldn't there be IE 5.5 for MAC OSX at least?
Thanks for the feedback.
Yeah, you're right. And even with IE on Linux under Wine I can not be 100% sure
whether I get the same behaviour as on Windows.
OT: is anybody aware of a good & user-friendly, maybe even free virtualization
product for MAC OS X that allows you to run Windows apps/a windows desktop
under MAC OS X?
I know there is Parallels, but $79 (+ Windows license) just to be able to run
shitty IE, is a bit too much IMHO.
"How to install IE6 on Mac OS X (Intel)"
> vmware is going to be beta'ing vmware for max os x
> to get on the beta list.
Cool, thanks for those two pointers. My sister (who is a designer) got a new
Intel Mac at work but they provide only Outlook Webaccess for non Outlook
users. This might come in very handy for her.
thanks a lot!
> but I just wanted to check if there is a more elegant solution for
Client-side validation is never a substitute for server-side
validation. Client-side is nice for pre-validating so bad input
doesn't hit the server and provide faster feedback to users, but you
should *always* validate any input that comes into your app (server-
side) from untrusted sources else Bad-Things could happen...
Just wanted to mention that.