Yeah, that's another thing that isn't clearly documented. In Wicket 1.0,
you need to explicitly include a CSS definition in the head section of
the page where you want the tree. See 'nested' of Wicket examples.
Wicket does not have 'native' javascript/css support in 1.0. In 1.1 (or
CVS HEAD),
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:
as eelco said this is deliberate in hangman.. (no cheating)
But i think the url shouldn't change either then.. You shouldn't see
version in that if there are no versions..
need to check this out.
If the same url is generated if versioning for a page is disabled, then
i think you have youre
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
Actually, there is some versioning still there. But if you
turn of default versioning (via Application.getSettings ()), it works
well. (resembles web islands behavior).
Shouldn't be all versioning turned off for hangman?
Btw. I tried another thing - add these headers to hangman
Btw. I tried another thing - add these headers to hangman
Cache-Control: must-revalidate
Pragma: no-cache
Expires: -1
but it didn't help. No page reload on back button (using firefox).
Does anyone know what else might help to force browser reload the page
on back button?
Do you know an
Well, these headers work with internet explorer. The page is properly
reloaded on back button. But it does not work with Firefox nor does it
work with opera. It think thigs would be easier if more browsers honored
this headers.
-Matej
Johan Compagner wrote:
Btw. I tried another thing
Hi,
It seems that updateModel() is called for invisible child components.
This causes an exception in the attached use case.
An IMHO crude workaround is to make all children explicitly invisible
instead of just setting the invisible state on the parent. However, the
FormComponent.IVistor in
I thought we fixed that in HEAD. Which version are you using?
Juergen
On 7/13/05, Johannes Fahrenkrug [EMAIL PROTECTED] wrote:
Hi,
It seems that updateModel() is called for invisible child components.
This causes an exception in the attached use case.
An IMHO crude workaround is to make
Ah, wait a minute... we do check whether the form component itself is
visible, but that component might have children that are visible. They
should not be included in updating and validating, but they might in the
current situation. Is that what you mean Johannes?
Eelco
Juergen Donnerstag
Hi,
well, I'm not using the CVS HEAD, I'm only using the 1.0 Tarball from
the SF page.
And yes, that is what I mean. My problem was this: I had a ListView and
within that another ListView and within that a DropDownChoice. I set
certain ListViewItems to invisible, but not the dropdownchoice that
Yep, that's a bug allright. Thanks for finding it. We'll fix it shortly
and have it shipped with 1.0.1 (hopefully this weekend).
Eelco
Johannes Fahrenkrug wrote:
Hi,
well, I'm not using the CVS HEAD, I'm only using the 1.0 Tarball from
the SF page.
And yes, that is what I mean. My problem
Hi,
it's me with my DropDownChoices again
Now I'm at the point where I have to validate the user input.
I have a (dynamic) list of DropDownChoices. It can have a variable
number of rows and each row has a DropDownChoice.
The user has to set at least one of the DropDownChoices to a non-zero
I started working on form level validation (which is what you want) some
time ago, but removed it from cvs again, as I thought it cluttered the
API too much/ was too hard to use. So, you should either write your
custom validator that is smart enough to work with more components, or
you should
Eelco,
JavaScript has the same reserved words and identifiers, in general, as Java.
Having said that, there really should be no issue as long as all the
component identifiers are quoted.
Shahid.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eelco
http://www.superinterface.com/wicketdialog does not work?
Eelco
Michael Jouravlev wrote:
On 7/13/05, Johan Compagner [EMAIL PROTECTED] wrote:
Do you know an example on the web where the back button triggers a
reload (When there is no POST message warning!!)
Never seen this. I did see
Have a look at
http://widlak.intrak.tuke.sk:8080/wicket1/library
It works similiar way.
But it will be online only for a limited time. Less then one hour
probably. I've no other place to put it online at this time.
Michael Jouravlev wrote:
On 7/13/05, Johan Compagner [EMAIL PROTECTED] wrote:
---
Not Found
The requested URL /wicketdialog was not found on this server.
---
It doesn't for me. What's supposed to be there?
-Matej
Eelco Hillenius wrote:
http://www.superinterface.com/wicketdialog does not work?
Eelco
Michael Jouravlev wrote:
On 7/13/05,
Personally, I would use another browser if it listened to web pages
instead of me. Just because the web designer thinks I need to refresh
the content when using the back button, doesn't mean I want to sit
there and wait for the new version to load. I like the back button for
what it's meant to be,
I was working with Johannes on the problem... a quick follow up:
We'd prefer if we could add the validator to the component to allow
better reuse instead of somehow doing validation on form level.
However, the problem currently is, that ListView is no subclass of
FormComponent so it doesn't
Hmm.. you can try
http://widlak.intrak.tuke.sk:8080/wicket1/displaytag
as well. But don't follow links to the link-omatic example :)
I hope it works and you can get through my firewall.
Matej Knopp wrote:
Have a look at
http://widlak.intrak.tuke.sk:8080/wicket1/library
It works similiar way.
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
On 7/13/05, Eelco Hillenius [EMAIL PROTECTED] wrote:
http://www.superinterface.com/wicketdialog does not work?
Eelco
Not yet :) Just yesterday I finally unpacked and built examples and
started looking at the code. I guess I will go with multi-panel Page,
seems the simplest choice for me.
On 7/14/05, Matej Knopp [EMAIL PROTECTED] wrote:
Have a look at
http://widlak.intrak.tuke.sk:8080/wicket1/library
It works similiar way.
But it will be online only for a limited time. Less then one hour
probably. I've no other place to put it online at this time.
Whoa, that is a cool one.
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.
Well, you can't logout. :) Because you can't logout in default wicket
library example too. The function is simply not there :)
I've done no modification to wicket. It's only one servlet filter,
that's all.
And I definitely wouldn't like this to be the default wicket behavior.
It's way *too
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
On 7/13/05, Phil Kulak [EMAIL PROTECTED] wrote:
Personally, I would use another browser if it listened to web pages
instead of me. Just because the web designer thinks I need to refresh
the content when using the back button, doesn't mean I want to sit
there and wait for the new version to
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
On 7/13/05, Michael Jouravlev [EMAIL PROTECTED] wrote:
See this thread for insight:
http://forums.mozillazine.org/viewtopic.php?t=99885start=0
I understand that by posting this link I can swing the scales to do
not reload decision, but again, I want to have an option for myself,
I do not
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
I decided to start a new thread about reload on Back. Despite of
whether we as server-side developers want to reload a page on going
back, or not, there are browsers. And browsers are different.
This thread is not about where page should be or should not be
reloaded on Back. It has more
Actually, I'm afraid that there's no way of having web islands working
with opera. Because even if the URL doesn't change, opera is still able
to go back.
-Matej
Michael Jouravlev wrote:
I decided to start a new thread about reload on Back. Despite of
whether we as server-side developers
Though the library we are looking at for supporting ajax, Dojo, actually
supports the back button with Ajax (don't know any details, but saw
discussions about this.
Eelco
Ajax does not leave much for
going back ;-)
---
This SF.Net
On 7/14/05, Matej Knopp [EMAIL PROTECTED] wrote:
Actually, I'm afraid that there's no way of having web islands working
with opera. Because even if the URL doesn't change, opera is still able
to go back.
Yes, that is exactly that I wanted to tell. But another idea that I
wanted to convey, is:
Riiight... I just checked with GMail. I have the list of emails with
some URL in the address bar. Then I selected one email, and GMail
loaded it via Ajax. URL is obviously the same. But then I clicked Back
and it returned to the list. Damn good, I'd say. They do it with some
javascript I am sure.
Actually, Johan allready made some changes this afternoon to get rid of
the ugly IRedirectListener (which is really not needed in the URL) and
the page version when there is no versioning done yet. Makes it much
nicer, and this discussion triggered him to work on that. Hopefully,
Johan will
Stefan,
actually only few components are derived from FormComponent. All
Links, Panels, Border, Page, WebMarkupContainer etc. are not. Please
excuse my silly question, but why should ListView be derived from
FormComponent. The component which you add to ListItem like CheckBox
etc. must be, and
Cool, looking forward to it. Let us know when you need help.
Eelco
Michael Jouravlev wrote:
I don't want to start advertising my stuff here, especially
considering that it is for Struts and for JSP. But in its current form
it does not really matter is it a complete page, or an element on a
I know this is a classloader issue, and probably all Tomcat's problem,
but I am getting these damn things all the time. When I make a change
and reload, this happens about half the time. It takes another reload
(or two) to get Tomcat to wake up and figure out that the class
exists. The reason I'm
I'm using jetty, everything from within Eclipse, and it works without
much trouble.
Juergen
On 7/13/05, Phil Kulak [EMAIL PROTECTED] wrote:
I know this is a classloader issue, and probably all Tomcat's problem,
but I am getting these damn things all the time. When I make a change
and reload,
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
I'm new to wicket so pardon me if I'm missing
something obvious. I'm using a ListView which
contains different types of items. In my markup, I
have several div sections where I only allow one to be
visible based on the type. I thought I could get away
not bothering to add the components in the
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
Oh man, this Jetty thing is great! Now I can debug and everything.
Thanks for the heads up. I haven't been doing this kind of stuff very
long, so it's nice to find out these little things. :)
-Phil
On 7/13/05, Eelco Hillenius [EMAIL PROTECTED] wrote:
Yeah, I don't think the WTP server support
Oh, I didn't know you worked on the Jetty Pluggin. Well, then thank
you very much. :)
On 7/13/05, Eelco Hillenius [EMAIL PROTECTED] wrote:
Thanks. At least makes up a bit for the hard nights I've been working on
it in the past - though I'm thankfull for the original developer, which
is the guy
58 matches
Mail list logo
