i just committed the change to cvs.
FormComponent has now a getInputName()
where the path of the component is generated from the form to the
component itself (form itself not included)
I also made that method non final so you can override it if you want
even a smaller name (if you know for sure for
example that the id also is unique within a form)
johan
Matej Knopp wrote:
I also think that it good for the component names not to be prepended
by form path. The rest of the path is always unique for the components
in form.
-Matej
Johan Compagner wrote:
we don't need the rest
we only need from the form (not included) to the component.
And if people are sure that id is also unique (what i know with
servoy) then we can just
put the id in it.
Because now the names are to long. PDA browsers have problems with it.
johan
Eelco Hillenius wrote:
We don't need the page id (I think). But we do need the rest in order
to support arbitrairy nesting, like including ListViews etc.
Ee;lco
On 9/6/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
I was just thinking..
Why are we using the complete path as the name?
Is that really needed?
Why not just the name itself?
Because now the paths can be come very very very long.
(if you have a form that is inside a view markup containers...)
i think we can do this:
protected void onComponentTag(final ComponentTag tag)
{
tag.put("name", getId());
super.onComponentTag(tag);
}
return getRequest().getParameter(getId());
Or is it possible that a form can have multiply components with the
same
name?
I am now thinking about a form that does have a listview inside it
iterating and making some components....
so:
tag.put("name", getParent().getId() + ":" + getId());
is also not enough i think. Because of a panel that has some
components
that is in a listview that is in a form...
i will make it so that it goes until the form.. Thet it is unique..
and
hopefully not that big.
And i don't make that method final (getInputName()). So that users
can
override it so they can generate
there own names in a form if they want that (if they know that getId()
is always unique then the can return that)
ok?
johan
johan
Matej Knopp wrote:
Eelco Hillenius wrote:
Yep. We could just strip the first nbr + '.'. That's not a big
problem.
nbr + ':' ;)
Great. Thanks for quick and positive feedback.
-Matej
Eelco
On 9/5/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
but the problem is this code:
protected void onComponentTag(final ComponentTag tag)
{
tag.put("name", getPath());
super.onComponentTag(tag);
}
getPath() returns with page id
And that is something for a name that we don't want (i can see why)
But for everything else it is something we want
because a getPath() is also used for creating urls (like
onChange of
Radio Choice)
And then we do need the id else we can't get the page.
So tag.put("name", getPathWithoutPageId());
and then getInput():
return getRequest().getParameter(getPathWithoutPageId());
Eelco Hillenius wrote:
I made getInput non-final, as this seems a reasonable flexibility
to want.
I'n not sure whether it is a good default to work with names
without
ids. I looks like a good idea as it supports the autocomplete
feature
you want, and there isn't anything we actually do with the page
id.
Can anyone think of disadvantages of doing this?
Eelco
On 9/5/05, Matej Knopp <[EMAIL PROTECTED]> wrote:
Okay, I'm not quite sure if I've expressed myself correctly. The
problem
is that browser's autocomplete is dependent on text input
name, which
changes according to page id.
Fortunately for me this can relative easely be fixed, overriding
TextField's onComponentTag and updateModel.
But it would be even easier, if getInput() wasn't final...
Or if in <input name="XXX"> XXX didn't contain page id.
Any ideas?
-Matej
Matej Knopp wrote:
Hi
I just want to ask whether it is necessary for the form
components to
contain page id in their names? Isn't it sufficient to have
page id
specified only in form action?
The fact is that the form components' names depend on the
current
page
id and things like browser's autocomplete just don't work
correctly.
This is very inconvenient in search boxes for example.
Does anyone know any workaround or is this just "feature"
that we
will
have to learn to live with? ;)
-Matej
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference &
EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference &
EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing
& QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
