client side appendable list of fields
Randall
a widget for which the client can append fields similar to this:
http://www.jsworkshop.com/dhtml/list18-2.html
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.
Randall
Jorge Godoy
I've done it with JavaScript. I would like to use a RepeatingWidget for that
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>
Randall
I would appreciate any feedback and I'll keep it available for a few
days.
-Randall
Steve Holden
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
Randall
Randall
Christopher Arndt
Hi!
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!
Chris
Randall
>
> - focus & select the first field when adding a field set.
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.
Agreed.
>
> - 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.
>
> - put the "Add"/"Remove" links on a separate <li> item, this makes styling easier.
Agreed.
>
>
> 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.
-Randall
Christopher Arndt
>> - focus & select the first field when adding a field set.
>
> 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?
Yes.
>> - you should be able to remove any field set, not just the last one.
>
> Agreed.
>
>> - 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.
Very easy:
connect(element or 'element_id', 'onsomething', function);
e.g.
connect(addlink_1, 'onclick',
function(event) {
/* passes form as element, not as element ID */
addItem(e.src().form);
}
);
/* 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
happens.
Chris
Karl Guertin
> 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?
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
javascript polish.
Randall
the page or just click here:
http://tnr.homeip.net:8081/static/dynwidget.tar.gz
That would be great since I'm not good with Javascript. Once
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.
Randall
Randall
Randall
Steve Holden
it interfaces really well!
I haven't started dealing with widgets yet, but it's nice to see what
can be done.
Christopher Arndt
- 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.
Chris
Randall
> Randall schrieb:
> > Added another example with a few changes.
> >
> > http://tnr.homeip.net:8081/
>
> - 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.
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.
Randall
Christopher Arndt
> Christopher Arndt wrote:
>> - 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.
>
> Yes. They should be empty.
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:
<FORM>
<UL>
<LI>
<LABEL FOR="fieldset_list">Label</LABEL>
</LI>
<LI>
<OL ID="fieldset_list">
<LI CLASS="appendablefieldset" ID="fieldset_0">
<UL>
<LI>
<LABEL>...</LABEL>
<INPUT ... />
</LI>
<LI>
<LABEL>...</LABEL>
<INPUT ... />
</LI>
</UL>
</LI>
....
</OL>
</LI>
<LI>
<A HREF="javascript:addItem('form_widget');" ID="doclink">Add ( + )</A>
</LI>
<LI>
<INPUT TYPE="submit" CLASS="submitbutton">
</LI>
</UL>
</FORM>
All the other SPANs and DIVs should not be necessary, if you do the JavaScript
properly.
Chris
Randall
widget. It seems important to me that the link be included with the
widget. The spans are necessary for styling since the contents of the
li can include the fields, error message, and help text, which must be
styled separately. Take a look at some of the template strings for
widgets included in TG to see examples.
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.
Randall
Randall
definition and appending the fields now puts focus on the new field.
There's no 'AJAX' going on, just DOM manipulation.
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.
Thanks. Randall
Steve Holden
rather than duplicating the contents of the first fields. Apart from
that, nice!
Randall
Randall
field(s) are present. I can't figure out how to present all of the
fields that were present before the POST. It's a cached view, so it
would need to be a client side solution I think. Any ideas?
Randall
Steve Holden
changes to the content (by setting InnerHTML or otherwise manipulating
the DOM) aren't recorded in the browser history, so the back button is
never likely to be that helpful, I'm afraid.
Randall
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.
Randall
Steve Holden
applications, and nobody seems to be screaming. I've never liked the
"back" button anyway :-)
Jorge Godoy
> 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
JavaScript to send the values back to the page where they were entered. If
you're populating these with data from the database, then it's just a matter
of reading them again.
¹ http://www.google.com.br/search?q=ajax+back+button
http://www.contentwithstyle.co.uk/Articles/38/
http://www.isolani.co.uk/blog/javascript/FixingTheBackButtonThatAjaxBroke
http://dev2dev.bea.com/pub/a/2006/01/ajax-back-button.html
http://www.onjava.com/pub/a/onjava/2005/10/26/ajax-handling-bookmarks-and-back-button.html
http://www.kryogenix.org/days/2005/03/11/applicationsButton
http://weblogs.asp.net/mschwarz/archive/2005/09/28/426156.aspx
...
--
Jorge Godoy <jgo...@gmail.com>
Randall
implementation. Is this something you think might belong in the
standard TG widget set? If so, I'll submit it as a feature request.
If not, I'll put it in the wiki. For convenience, here's the link
again:
I would appreciate it if someone tested this on IE. I've only got
Mozilla and Safari.
Randall
Julio Oña
First field should have Remove (-) too, and it should be disable when only one line is remainding.
Regards.
Jorge Godoy
There's a bug in it.
How to reproduce:
- Remove "John Doe"
- Add a new line
- Remove the added line
- it will stay there
- "Jane Doe" will be removed instead
Be seeing you,
--
Jorge Godoy <jgo...@gmail.com>
Jorge Godoy
> Hi, nice work,
> First field should have Remove (-) too, and it should be disable when only one line is
> remainding.
> Regards.
Unless he fixed it, it already does have the remove option. At least now,
23h33 UTC. :-)
--
Jorge Godoy <jgo...@gmail.com>
Randall
Randall
Jorge Godoy
> Nice catch. Thanks!
You're welcome. Just be sure to tell us here when you fix that. ;-)
--
Jorge Godoy <jgo...@gmail.com>
Randall
Jorge Godoy
Christopher Arndt
> I would appreciate it if someone tested this on IE. I've only got
> Mozilla and Safari.
In IE 6 (under Wine) I get the following JavaScript error when I click on "Add
(+)":
Line: 61
Char: 17
Error: 'label.getAttribute(...)' is null or not an object
Code: 0
(translated from German)
BTW, If you were using Linux, I'd recommend you have a look at this:
http://www.tatanka.com.br/ies4linux/page/Main_Page
But shouldn't there be IE 5.5 for MAC OSX at least?
Chris
Randall
consider it to be the same as IE on Windows. I once found a javascript
bug that presented on OS X Safari, Camino, and IE, but not on Linux
Firefox or Windows IE. I guess they use a common Javascript engine.
Not sure.
Thanks for the feedback.
Randall
Christopher Arndt
> For some unknown reason, IE 5.5 on my Mac just hangs now and I don't
> consider it to be the same as IE on Windows.
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.
Chris
Lee McFadden
and got in on the cheap introductory offer.
Lee
--
Lee McFadden
blog: http://www.splee.co.uk
work: http://fireflisystems.com
skype: fireflisystems
José de Paula Eufrásio Júnior
>
> There is Q (or kju) - I've never used it as i beta tested parallels
> and got in on the cheap introductory offer.
Hmm...
http://darwine.opendarwin.org/
keep an eye. they're moving fast.
--
José de Paula Eufrásio Júnior
aka coredump
http://core.eti.br
Jeff Hinrichs - DM&T
http://vmware.rsc02.net/servlet/campaignrespondent?_ID_=vmwi.1756
to get on the beta list.
Jeff Hinrichs - DM&T
"How to install IE6 on Mac OS X (Intel)"
http://www.z3lab.org/sections/blogs/philipp-weitershausen/2006_11_30_how-to-install-ie6-on
--
Jeff Hinrichs
Dundee Media & Technology, Inc
je...@dundeemt.com
402.320.0821
Christopher Arndt
> Just saw this in my feeds:
>
> "How to install IE6 on Mac OS X (Intel)"
> http://www.z3lab.org/sections/blogs/philipp-weitershausen/2006_11_30_how-to-install-ie6-on
> vmware is going to be beta'ing vmware for max os x
> http://vmware.rsc02.net/servlet/campaignrespondent?_ID_=vmwi.1756
> 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.
Chris
miya
There's one problem though, once you create new TextFields (Input
Fields) via Javascript, I cannot longer use the 'validator framework'
provided by TG. It works for those fields that were not created via
javascript.
Do you guys have (or think of) some kind of hack to keep using the
'validator framework'?
I know that I could validate in the client side using more javascript,
but I just wanted to check if there is a more elegant solution for this
problem.
thanks a lot!
--
miya
Alberto Valverde
On Dec 14, 2006, at 8:08 PM, miya wrote:
> I know that I could validate in the client side using more javascript,
> but I just wanted to check if there is a more elegant solution for
> this
> problem.
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.
Alberto