That would be pretty difficult I think. Say, you used 'foo.bar' as your
component name, and we translate it to 'foo:bar' internally. We we still
have to figure out that in the markup it is denoted as 'foo.bar' (so we
have to keep the original), but for generating links etc, we would use
the
Why do you need it *after* action was performed and redirect was made?
When I load forminput example for the first time, it is loaded with
GET and URL is clean:
http://www.wicket-library.com/wicket-examples/forminput
After I submit a form, the following stuff is added to URL:
I have no preference other than the colon makes my code look a bit neater!
Chris
Martijn Dashorst wrote:
I am in the 'want to use the component id as (limited) ognl
expression' camp. I think that the component seperator should be
either colon (:) or dollar sign ($). Visually I have a
So, it seems that most prefer the colon (Juergen too btw). Do any of you
foresee problems with Javascript? One thing we need to be able to do is
refer to components in Javascript using their component paths. I'm not
sure whether the colon works. Anyone willing to test this?
Eelco
Chris
Hillenius
Sent: Wednesday, July 13, 2005 4:12 AM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] poll: what should we use as our component's path
seperator?
So, it seems that most prefer the colon (Juergen too btw). Do any of you
foresee problems with Javascript? One thing we need
Yes, but C++ uses :: for defining class methods. That's actually why
I'm drawn to the single colon, plus it looks nice.
On 7/13/05, Martijn Dashorst [EMAIL PROTECTED] wrote:
I am in the 'want to use the component id as (limited) ognl expression'
camp. I think that the component seperator should
Sorry, I disagree here. I think that it would bring unnecessary complexity.
Actually, only the URLs will change. It should not affect any existing
wicket programs. The user really doesn't have to care, if the components
in url are separated by '.' or ':'.
It really has nothing to do with class
As soon as it affects Javascript (which Eelco mentioned it would) it
becomes a user problem. And the unncessary complexity is all under the
hood, where it should remain.
Gili
Matej Knopp wrote:
Sorry, I disagree here. I think that it would bring unnecessary complexity.
Actually, only the
I don't know what's the state of current ajax implementation, but I
think that all references of wicket components for javascript will be
server generated, not made directly by user. Still I don't think user
will deal with this.
It's simple. If we will have '.' as separator in component
No, Eelco stated that we might need to examine whether it would affect
JavaScript.
And I agree with Matej Knopp. Having Wicket trying to sort out what the
idea is of form.1.foo.bar (where does the component path end and
begins the navigation) is too complex, and according to me impossible.
From my past experience with Wicket: there will *always* be situations
where Wicket doesn't do exactly what you want/need and you need to
create your own component. Some components will inevitably use
Javascript and you will have to refer to the wicket components.
As for the exact syntax,
That's fine as long as under the hood does not leak into URLs and
Javascript because you will inevitably have to interact with those in
your custom components or crawlers that freak out over weird syntax.
Gili
Martijn Dashorst wrote:
No, Eelco stated that we might need to examine whether
The only concern I can find with the selector is that it should be CSS
selector compliant. So we can't use . I'm not sure about :.
From the HTML 4 spec:
*ID* and *NAME* tokens must begin with a letter ([A-Za-z]) and may be
followed by any number of letters, digits ([0-9]), hyphens (-),
Hey,
i was following the discussion and want to share my thoughts...
I view it like that: If it's really only internal (meaning relevant for
the developers developing *the* wicket framework itself for debugging) it
should by no means matter what you use. Just use the simplest and fastest
thing
Matej Knopp wrote:
Once again. There's no way for wicket to decide wheter '.' separates
components or it's a part of component name. It's ambiguous.
Therefore today '.' can't be part of component name. And that's what's
wrong. OGNL supports nested beans and this way it can't be used.
When
The ambiguity is when wicket parses the url. That's the point.
when you have URL something like this:
1.something.foo.bar.panel
can you tell that foo.bar are two components or one?
say component 'something' has two components:
panel 'foo' (which can have child 'bar')
and panel 'foo.bar'
how
Gili wrote:
Matej Knopp wrote:
Once again. There's no way for wicket to decide wheter '.' separates
components or it's a part of component name. It's ambiguous.
Therefore today '.' can't be part of component name. And that's what's
wrong. OGNL supports nested beans and this way it can't be
As I've already said, i think I have some components with '-' in their
name. But that's not an issue, it's easy to rename.
To decide between ':' and '-': Hmm.. I think there's no real argument
against '-' in favour of ':', except that ':' seem to be more
aesthetical to me :)
-Matej
Martijn
Thank you for clearing this up. You are right :)
My only remaining concern is URL crawlability. Please ensure that
whatever is chosen can be easily incorporated into friendly URLs in
the future.
Thanks again,
Gili
Matej Knopp wrote:
The ambiguity is when wicket parses the url.
On 7/13/05, Johan Compagner [EMAIL PROTECTED] wrote:
We could get rid of the interface=IRedirectListener and if a request is
made for:
http://www.wicket-library.com/wicket-examples/forminput?component=0version=0
then that IRedirectListener is implied.
But getting rid of component=0version=0
Matej, thank you for the explanation. I still have couple of questions.
Johan, if you read this email, I see that you removed reference to
IRedirectListener as well as version number if page is not versioned.
Thanks, this is great news. I still do not quite understand the
following:
=== cut here
Another question is several instances of the same page. You wrote that
bookmarkable link creates a new page instance, thus the page gets new
id. Why would one need several instances of the same logical page? In
the same session? In the same window?
Because they could be logically
Okay, I don't object and vote for ':'.
Eelco Hillenius wrote:
We have plans to replace the current dot ('.') seperator in component
paths by another character. The main reason for wanting this, is to
avoid conflicts with Ognl, and be able to use nested properties more
easily. E.g., when that
My vote: Page:SomePanel:SomeComponent
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eelco
Hillenius
Sent: Tuesday, July 12, 2005 6:41 PM
To: Wicket User List
Subject: [Wicket-user] poll: what should we use as our component's path
seperator?
We have
- or :
where can it be used/output to now or maybe in the further?
For example urls/javascript? Should we look if there are pit holes there?
Eelco Hillenius wrote:
We have plans to replace the current dot ('.') seperator in component
paths by another character. The main reason for wanting
If I understand it correctly, the bean looks like this
class BeanClass {
Company company;
// setters, getters
}
the component id is company.name and it's bound to the company.name
property of the BeanClass object.
Phil Kulak wrote:
I like the colon myself, but I'm a little confused
Actually, I'd leave this to the url encrypter, because using '/'
properly would mean changing the url structure.
having
...library?component=7.border/books/2/moveDownversion=0interface=ILinkListener
instead of
...library?component=7.border.books.2.moveDownversion=0interface=ILinkListener
resp.
Well, I think that the default URL scheme is made to be as simple as
possible.
If you don't like it, you are free to implement you own url obsfucation.
See wicket wiki for more detail.
The ILinkListener indicates, which method of the target object is called
upon action.
Nevertheless, I think
On 7/13/05, Matej Knopp [EMAIL PROTECTED] wrote:
Well, I think that the default URL scheme is made to be as simple as
possible.
If you don't like it, you are free to implement you own url obsfucation.
See wicket wiki for more detail.
Thanks, I will take a look.
The ILinkListener indicates,
Hmm.. the thread is already polluted, not much to save here.
First request is made with ILinkListener (or IFormSubmitListener, etc).
The action on target object is performed.
Second request (after redirect) is made with IRedirectListener, and the
target object is page.
And I certainly don't
30 matches
Mail list logo
