Re: Html dir attribute
Yeah thats it. Numbers are LTR & text is RTL. On 11/14/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: On 11/14/06, Iman Rahmatizadeh <[EMAIL PROTECTED]> wrote: > I guess this should work ok, so this way pages written previously wont be > harmed, and we have support for programmatically setting the direction. > Eelco, wouldn't you consider adding the method to Component instead of > WebPage ? Well, the thing is that adding it yourself to a component (attribute modifier) or tag is easy enough, while the key thing I wanted to achieve here is that in a case like FormInput, you don't have to have a separate markup file for RTL locale just in order to get the dir attribute in the tag. An exception where it makes sense to put in a component is the example you gave for text fields. Numeric text fields in RTL locales should be LTR, correct? Are there any other of such cases? Eelco
Re: JIRA as our changes.xml
Ok, let me know when its needed. Erik. Igor Vaynberg schreef: On 11/13/06, Erik van Oosten <[EMAIL PROTECTED]> wrote: What the heck, I'll volunteer to write those release notes if someone gives me that jira list. https://issues.apache.org/jira/browse/WICKET?report=com.atlassian.jira.plugin.system.project:changelog-panel :) -igor Erik. Igor Vaynberg schreef: > what about them do you find unreadable? > > i would be +1 for this. keeping up changes.xml is a pain imho, and > since a > good amount will already be entered into jira it will take work off us. > > -igor -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: Html dir attribute
On 11/14/06, Iman Rahmatizadeh <[EMAIL PROTECTED]> wrote: I guess this should work ok, so this way pages written previously wont be harmed, and we have support for programmatically setting the direction. Eelco, wouldn't you consider adding the method to Component instead of WebPage ? Well, the thing is that adding it yourself to a component (attribute modifier) or tag is easy enough, while the key thing I wanted to achieve here is that in a case like FormInput, you don't have to have a separate markup file for RTL locale just in order to get the dir attribute in the tag. An exception where it makes sense to put in a component is the example you gave for text fields. Numeric text fields in RTL locales should be LTR, correct? Are there any other of such cases? Eelco
Re: Package org.apache.wicket?
+1 Juergen On 11/13/06, Frank Bille <[EMAIL PROTECTED]> wrote: yeah +1 to that On 11/13/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > yeah, what eelco said. > > -igor > > > > I'm all for only changes the packages for 2.0. I still would like to > > keep the breaks for 1.3 minimal, and generally get it over with asap. > > Doing it just before the first public release sounds fine to me. > > > > Eelco > > > >
Re: Html dir attribute
I guess this should work ok, so this way pages written previously wont be harmed, and we have support for programmatically setting the direction. Eelco, wouldn't you consider adding the method to Component instead of WebPage ? On 11/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: This would be the minimal thing to make a RTL language look ok. Japanese for instance is a LTR language (like English and German are). Eelco On 11/13/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > I'm not sure. Isn't it that the whole form / page layout require > changes to make it look right. Same is true for japanese etc. That is > why we allow for per locale properties file. > > Juergen > > On 11/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I converted the form input example this weekend so that it uses one > > page and a properties (or xml) file per supported locale. One problem > > I have to fix is the fact that Persian (fa IR) is a 'left-to-right' > > language (see http://www.i18nguy.com/markup/right-to-left.html). > > > > Now, it kind of sucks to have to use a separate markup file for just > > to insert this tag: > > > > (or http://www.w3.org/1999/xhtml"; dir="rtl">) > > > > I was thinking, maybe we could do this automatically. What we could do is this: > > * recognize the tags so that we can access them later (much > > like we do with the tags now); > > * have a getDir or getDirection method in WebPage that works like this: > > - If it returns LTR or RTL, a dir attribute is set on the tag; > > - if it returns null and the locale is LTR, nothing is done > > - if it returns null and the locale is RTL, dir="rtl" is set on > > the tag. > > > > WDYT? > > > > Eelco > > >
Re: Package org.apache.wicket?
yeah +1 to that On 11/13/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: yeah, what eelco said. -igor I'm all for only changes the packages for 2.0. I still would like to > keep the breaks for 1.3 minimal, and generally get it over with asap. > Doing it just before the first public release sounds fine to me. > > Eelco >
Re: Package org.apache.wicket?
yeah, what eelco said. -igor I'm all for only changes the packages for 2.0. I still would like to keep the breaks for 1.3 minimal, and generally get it over with asap. Doing it just before the first public release sounds fine to me. Eelco
Re: Package org.apache.wicket?
On 11/13/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Before we start a vote for renaming our package structure, I think we should carefully consider the consequences. The proposal is to rename our wicket.* package to org.apache.wicket.* There is no requirement within Apache to do so, but it can/will save some discussions on general@ and later on in our live as Apache project If I remember correctly the idea was to rename the package structure only for wicket 2.0, as this version already breaks API compatibility. Now the problem comes with keeping both 1.3 and 2.0 in sync. Bugs found or new features in 2.0 can (with some effort) be backported fairly easy and vice versa. When we change the package structure to org.apache.wicket, it will be a lot harder to apply a patch between the two branches. So how should we go about this? We could *not* move, and keep the package the way it currently is. We could move both 1.3 and 2.0 before the first release to org.apache.wicket, breaking the api for 1.3 considerably, but in a very predictable manner. We could even supply a refactor script for this. We could only move 2.0, and only just before our first public developer release. What do you think? I'm all for only changes the packages for 2.0. I still would like to keep the breaks for 1.3 minimal, and generally get it over with asap. Doing it just before the first public release sounds fine to me. Eelco
Re: wicket-examples
But anyway are you willing/have enough rights to change the license to ASL? Else I will add them to NOTICE.txt Frank Yep. I'm the author, and I'm fine with doing that. Eelco
Re: Re: wicket-examples
On 11/13/06, Frank Bille <[EMAIL PROTECTED]> wrote: But anyway are you willing/have enough rights to change the license to ASL? Else I will add them to NOTICE.txt He's the original author, regardless of the quality :-). Move the code to the wicket namespace, and change to ASL. Or let Eelco do so (with a critical eye) to be on the safe side. Another option would be to flag it for removal/replacement. I have no special attachment to these files, other than that they help run our tests. With selenium-rc I think we can improve on our tests for extensions though. Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Package org.apache.wicket?
Before we start a vote for renaming our package structure, I think we should carefully consider the consequences. The proposal is to rename our wicket.* package to org.apache.wicket.* There is no requirement within Apache to do so, but it can/will save some discussions on general@ and later on in our live as Apache project If I remember correctly the idea was to rename the package structure only for wicket 2.0, as this version already breaks API compatibility. Now the problem comes with keeping both 1.3 and 2.0 in sync. Bugs found or new features in 2.0 can (with some effort) be backported fairly easy and vice versa. When we change the package structure to org.apache.wicket, it will be a lot harder to apply a patch between the two branches. So how should we go about this? We could *not* move, and keep the package the way it currently is. We could move both 1.3 and 2.0 before the first release to org.apache.wicket, breaking the api for 1.3 considerably, but in a very predictable manner. We could even supply a refactor script for this. We could only move 2.0, and only just before our first public developer release. What do you think? Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: wicket-examples
On 11/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > What about a file like this: > http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket-examples/src/test/java/nl/openedge/util/jetty/JettyMonitorException.java?view=co Case of a stupid slip. I'll testify that in front of a jury :) Hehe, does it say "All rights reserved?" But anyway are you willing/have enough rights to change the license to ASL? Else I will add them to NOTICE.txt Frank
Re: wicket-examples
What about a file like this: http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket-examples/src/test/java/nl/openedge/util/jetty/JettyMonitorException.java?view=co Case of a stupid slip. I'll testify that in front of a jury :) Eelco
Re: wicket-examples
On 11/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: That code was released with the BSD licence. I'm not sure how the ownership works; I wrote it for openedge/ topicus, but mostly in my spare time I believe. IMNAL either, but we should be ok. What about a file like this: http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket-examples/src/test/java/nl/openedge/util/jetty/JettyMonitorException.java?view=co
Re: [VOTE] remove RequiredTextField in 2.0/1.3
[ ] yes remove RequiredTextField in 2.0 and 1.3 [ x ] yes remove RequiredTextField in 2.0 only [ ] no, but move it to wicket-extensions [ ] no, I'm very attached to RequiredTextField and would keep it where it is. I see no advantage to removing it from 1.3 as well; it'll only make upgrading harder for users. Eelco
Re: [VOTE] remove RequiredTextField in 2.0/1.3
[x] yes remove RequiredTextField in 2.0 only -igor
[VOTE] remove RequiredTextField in 2.0/1.3
To cut down on our API and remove some ultra-convenience stuff, I propose to remove RequiredTextField from our API. Requiredness is easily achieved using 'setRequired(true)', and therefore removes the need for a special field. [ ] yes remove RequiredTextField in 2.0 and 1.3 [ ] yes remove RequiredTextField in 2.0 only [ ] no, but move it to wicket-extensions [ ] no, I'm very attached to RequiredTextField and would keep it where it is. Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: wicket-examples
The httpunit license is MIT or BSD type: http://httpunit.sourceforge.net/doc/license.html > src/test/java/nl/openedge/util/jetty (some files has a non-ASL license > header which I haven't looked through yet, and some has a short copyright > notice in Dutch) This one can be changed by either me or Eelco. Eelco was the original author I believe. It is not that much magic that is going on there, easily retrofitted for ASL imo. I'm not a lawyer, but if Eelco modifies the package name from nl.openedge to org.apache.wicket, and fixes the header it should be ok. That code was released with the BSD licence. I'm not sure how the ownership works; I wrote it for openedge/ topicus, but mostly in my spare time I believe. IMNAL either, but we should be ok. Eelco
Re: Severe Bug in Wicket 2 / WICKET-42
i dont think this is a very common usecase, at least it has never been
requested before. so what i am tempted to tell you is to implement your own
IRequestCodingStrategy to handle this. and if you would like you can provide
it as a patch and we might put it into extensions or core.
-igor
On 11/13/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
Hi Johan,
yes i know its not component, and its evil :O
the *.html would mean a unique identifier where a filter could be attached
to and so static resources wouldnt be touched.
The one class - well, i know its a hard discussion, but as we also have
wicket-apps where whole app is just 1 page that swaps around components in
it this doenst sound too exotic for me.
regards
> -Ursprüngliche Nachricht-
> Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 13. November 2006 20:29
> An: wicket-dev@incubator.apache.org
> Betreff: Re: Severe Bug in Wicket 2 / WICKET-42
>
> you can have .html just fine.
> Only you want to have xxx/param.html?
> so like:
>
> /product/110203.html?
> or
> /product/id/110203.html?
>
> Why that html there?
> What does that bring?
> I don't find it nicer that is just taste.
> And i guess you could build it just fine. Just make another
> url encoder.
>
> And having one class handling everything.. a really really
> big YUK or ARRGGH
>
> thats horrible. We are in a component oriented framework
> here. Where small pieces do there job Not one big page where
> you parse the page parameters.
>
> You could do this by the way just fine now.
> Only have have to mount those pages not on / (thats homepage)
> but on /mybigentry
>
>
> johan
>
>
>
> On 11/13/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> >
> > Yeah similar to that. I mean we currently even cant employ
> file-endings.
> >
> > e.g: you can have /page/param/param
> > but not /page/param/param.html wich would be even more nice
> and logic
> > (IMHO)
> >
> > imagine a mount where you could specify "/" as begin and ".htm" as
> > end. -> you could have 1 handling-class for all data as well as
> > natural URLs (if you use IndexedURLParams).
> > if / is solely you could return the start page, if /.htm is called
> > wicket knows that it would be the handling-class with empty
> > params...so we also wouldnt crash with any other wicket
> functionality.
> >
> > e.g: globalmount(".htm", new
> > IndexedUrlParamStrategy("/",handler.class));
> > so you also would centralise URLs to just 1 class in app
> wich then can
> > delegate to the resulting pages.
> >
> > was just a thought from what im in now as i need nice URLs and the
> > problems i stumbled in regarding static content, root etc.
> >
> > what do you think about this? - i'm interested in any
> thoughts about it.
> >
> > Best Regards,
> >
> > Korbinian
> >
> >
> >
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > Gesendet: Montag, 13. November 2006 10:20
> > > An: wicket-dev@incubator.apache.org
> > > Betreff: Re: Severe Bug in Wicket 2 / WICKET-42
> > >
> > > So this way?
> > >
> > > / == home page
> > > /?p=a == homepage with page params.
> > > /?interface:xxx == an callback to an existing page
> > > /?bookmarkablePage=xxx == an none mounted bookmarkable
> page request
> > > /input == mounted bookmarkable page
> > >
> > > and then
> > >
> > > /a == this is not mounted like input above.. Then it
> should go to a
> > > page that was mounted on /* ??
> > > So you want to have a fallback to a page?
> > >
> > > johan
> > >
> > >
> > >
> > > On 11/12/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Yeah, that is what i mean -
> > > >
> > > > e.g: mount to /*.html -> would mean it goes for
> /[everything].html
> > > > wich would introduce even more flexibility...
> > > >
> > > > currently, it goes to "/[neededCharacter]" and this catches
> > > > /[neededCharacter][anythingBehind]
> > > > e.g: /a ->
> > > > /a/b is valid
> > > > /aa/b is valid
> > > > /a is valid
> > > >
> > > > as / is mounted for the homepage and you cant mount a
> > > wildcard so far,
> > > > you still need a fixed point you can hook on.
> > > >
> > > > Regards
> > > >
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > > > Gesendet: Sonntag, 12. November 2006 20:15
> > > > > An: wicket-dev@incubator.apache.org
> > > > > Betreff: Re: Severe Bug in Wicket 2 / WICKET-42
> > > > >
> > > > > what does a page mounted on /* means in your eyes?
> > > > > /[everything]??
> > > > >
> > > > > there is no such a thing like wild card mounting.
> > > > >
> > > > > johan
> > > > >
> > > > >
> > > > > On 11/12/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Hi Igor,
> > > > > >
> > > > > > yes - but its not mounted to "/*" but to "/" - is it
> > > > > possible to have
> > > > > > the homepage mounted on "/*" ? means that this page gets
> > > > > all path as
> > > > > > indexedURLparams??
> > > > > >
> > > > >
Re: wicket-examples
On 11/13/06, Frank Bille <[EMAIL PROTECTED]> wrote: src/test/java/com/meterware/httpunit (doesn't seem to be used, no license header at all) This was a fix for XML and/or JavaScript not being parsed correctly, iirc. The httpunit license is MIT or BSD type: http://httpunit.sourceforge.net/doc/license.html src/test/java/nl/openedge/util/jetty (some files has a non-ASL license header which I haven't looked through yet, and some has a short copyright notice in Dutch) This one can be changed by either me or Eelco. Eelco was the original author I believe. It is not that much magic that is going on there, easily retrofitted for ASL imo. I'm not a lawyer, but if Eelco modifies the package name from nl.openedge to org.apache.wicket, and fixes the header it should be ok. Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
wicket-examples
I'm not *that* familiar with wicket-examples so I would like to hear about if anyone knows if there are any legal issues in it know and if all the source code in it is ASL (compliant). In particular I'm thinking about these folders: src/test/java/com/meterware/httpunit (doesn't seem to be used, no license header at all) src/test/java/nl/openedge/util/jetty (some files has a non-ASL license header which I haven't looked through yet, and some has a short copyright notice in Dutch) Anything else? Frank
AW: Severe Bug in Wicket 2 / WICKET-42
Hi Johan,
yes i know its not component, and its evil :O
the *.html would mean a unique identifier where a filter could be attached
to and so static resources wouldnt be touched.
The one class - well, i know its a hard discussion, but as we also have
wicket-apps where whole app is just 1 page that swaps around components in
it this doenst sound too exotic for me.
regards
> -Ursprüngliche Nachricht-
> Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 13. November 2006 20:29
> An: wicket-dev@incubator.apache.org
> Betreff: Re: Severe Bug in Wicket 2 / WICKET-42
>
> you can have .html just fine.
> Only you want to have xxx/param.html?
> so like:
>
> /product/110203.html?
> or
> /product/id/110203.html?
>
> Why that html there?
> What does that bring?
> I don't find it nicer that is just taste.
> And i guess you could build it just fine. Just make another
> url encoder.
>
> And having one class handling everything.. a really really
> big YUK or ARRGGH
>
> thats horrible. We are in a component oriented framework
> here. Where small pieces do there job Not one big page where
> you parse the page parameters.
>
> You could do this by the way just fine now.
> Only have have to mount those pages not on / (thats homepage)
> but on /mybigentry
>
>
> johan
>
>
>
> On 11/13/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> >
> > Yeah similar to that. I mean we currently even cant employ
> file-endings.
> >
> > e.g: you can have /page/param/param
> > but not /page/param/param.html wich would be even more nice
> and logic
> > (IMHO)
> >
> > imagine a mount where you could specify "/" as begin and ".htm" as
> > end. -> you could have 1 handling-class for all data as well as
> > natural URLs (if you use IndexedURLParams).
> > if / is solely you could return the start page, if /.htm is called
> > wicket knows that it would be the handling-class with empty
> > params...so we also wouldnt crash with any other wicket
> functionality.
> >
> > e.g: globalmount(".htm", new
> > IndexedUrlParamStrategy("/",handler.class));
> > so you also would centralise URLs to just 1 class in app
> wich then can
> > delegate to the resulting pages.
> >
> > was just a thought from what im in now as i need nice URLs and the
> > problems i stumbled in regarding static content, root etc.
> >
> > what do you think about this? - i'm interested in any
> thoughts about it.
> >
> > Best Regards,
> >
> > Korbinian
> >
> >
> >
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > Gesendet: Montag, 13. November 2006 10:20
> > > An: wicket-dev@incubator.apache.org
> > > Betreff: Re: Severe Bug in Wicket 2 / WICKET-42
> > >
> > > So this way?
> > >
> > > / == home page
> > > /?p=a == homepage with page params.
> > > /?interface:xxx == an callback to an existing page
> > > /?bookmarkablePage=xxx == an none mounted bookmarkable
> page request
> > > /input == mounted bookmarkable page
> > >
> > > and then
> > >
> > > /a == this is not mounted like input above.. Then it
> should go to a
> > > page that was mounted on /* ??
> > > So you want to have a fallback to a page?
> > >
> > > johan
> > >
> > >
> > >
> > > On 11/12/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Yeah, that is what i mean -
> > > >
> > > > e.g: mount to /*.html -> would mean it goes for
> /[everything].html
> > > > wich would introduce even more flexibility...
> > > >
> > > > currently, it goes to "/[neededCharacter]" and this catches
> > > > /[neededCharacter][anythingBehind]
> > > > e.g: /a ->
> > > > /a/b is valid
> > > > /aa/b is valid
> > > > /a is valid
> > > >
> > > > as / is mounted for the homepage and you cant mount a
> > > wildcard so far,
> > > > you still need a fixed point you can hook on.
> > > >
> > > > Regards
> > > >
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > > > Gesendet: Sonntag, 12. November 2006 20:15
> > > > > An: wicket-dev@incubator.apache.org
> > > > > Betreff: Re: Severe Bug in Wicket 2 / WICKET-42
> > > > >
> > > > > what does a page mounted on /* means in your eyes?
> > > > > /[everything]??
> > > > >
> > > > > there is no such a thing like wild card mounting.
> > > > >
> > > > > johan
> > > > >
> > > > >
> > > > > On 11/12/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Hi Igor,
> > > > > >
> > > > > > yes - but its not mounted to "/*" but to "/" - is it
> > > > > possible to have
> > > > > > the homepage mounted on "/*" ? means that this page gets
> > > > > all path as
> > > > > > indexedURLparams??
> > > > > >
> > > > > > if i mount it to /* he doesnt see it as wildcard but as
> > > fixed "*"
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > >
> > > > > > > -Ursprüngliche Nachricht-
> > > > > > > Von: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> > > > > > > Gesendet: Sonntag, 12. November 2006 18:39
> > > > > > > An: wi
Re: JIRA as our changes.xml
On 11/13/06, Erik van Oosten <[EMAIL PROTECTED]> wrote: What the heck, I'll volunteer to write those release notes if someone gives me that jira list. https://issues.apache.org/jira/browse/WICKET?report=com.atlassian.jira.plugin.system.project:changelog-panel :) -igor Erik. Igor Vaynberg schreef: > what about them do you find unreadable? > > i would be +1 for this. keeping up changes.xml is a pain imho, and > since a > good amount will already be entered into jira it will take work off us. > > -igor -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: JIRA as our changes.xml
What I don't like is that is a plain list without any notion on what is important and what is not. Of course, its ok to maintain the changes in a tracking system. But presenting the list of changes exactly as they come from Jira is pretty hard on the reader. It should be fun to read change notes, its what makes you want to use the new stuff. So release notes are an important part of the product. What the heck, I'll volunteer to write those release notes if someone gives me that jira list. Erik. Igor Vaynberg schreef: what about them do you find unreadable? i would be +1 for this. keeping up changes.xml is a pain imho, and since a good amount will already be entered into jira it will take work off us. -igor -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: Severe Bug in Wicket 2 / WICKET-42
you can have .html just fine.
Only you want to have xxx/param.html?
so like:
/product/110203.html?
or
/product/id/110203.html?
Why that html there?
What does that bring?
I don't find it nicer that is just taste.
And i guess you could build it just fine. Just make another url encoder.
And having one class handling everything.. a really really big YUK or ARRGGH
thats horrible. We are in a component oriented framework here. Where small
pieces do there job
Not one big page where you parse the page parameters.
You could do this by the way just fine now.
Only have have to mount those pages not on / (thats homepage) but on
/mybigentry
johan
On 11/13/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
Yeah similar to that. I mean we currently even cant employ file-endings.
e.g: you can have /page/param/param
but not /page/param/param.html wich would be even more nice and logic
(IMHO)
imagine a mount where you could specify "/" as begin and ".htm" as end. ->
you could have 1 handling-class for all data as well as natural URLs (if
you
use IndexedURLParams).
if / is solely you could return the start page, if /.htm is called wicket
knows that it would be the handling-class with empty params...so we also
wouldnt crash with any other wicket functionality.
e.g: globalmount(".htm", new IndexedUrlParamStrategy("/",handler.class));
so you also would centralise URLs to just 1 class in app wich then can
delegate to the resulting pages.
was just a thought from what im in now as i need nice URLs and the
problems
i stumbled in regarding static content, root etc.
what do you think about this? - i'm interested in any thoughts about it.
Best Regards,
Korbinian
> -Ursprüngliche Nachricht-
> Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 13. November 2006 10:20
> An: wicket-dev@incubator.apache.org
> Betreff: Re: Severe Bug in Wicket 2 / WICKET-42
>
> So this way?
>
> / == home page
> /?p=a == homepage with page params.
> /?interface:xxx == an callback to an existing page
> /?bookmarkablePage=xxx == an none mounted bookmarkable page request
> /input == mounted bookmarkable page
>
> and then
>
> /a == this is not mounted like input above.. Then it should
> go to a page that was mounted on /* ??
> So you want to have a fallback to a page?
>
> johan
>
>
>
> On 11/12/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> >
> > Yeah, that is what i mean -
> >
> > e.g: mount to /*.html -> would mean it goes for /[everything].html
> > wich would introduce even more flexibility...
> >
> > currently, it goes to "/[neededCharacter]" and this catches
> > /[neededCharacter][anythingBehind]
> > e.g: /a ->
> > /a/b is valid
> > /aa/b is valid
> > /a is valid
> >
> > as / is mounted for the homepage and you cant mount a
> wildcard so far,
> > you still need a fixed point you can hook on.
> >
> > Regards
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > Gesendet: Sonntag, 12. November 2006 20:15
> > > An: wicket-dev@incubator.apache.org
> > > Betreff: Re: Severe Bug in Wicket 2 / WICKET-42
> > >
> > > what does a page mounted on /* means in your eyes?
> > > /[everything]??
> > >
> > > there is no such a thing like wild card mounting.
> > >
> > > johan
> > >
> > >
> > > On 11/12/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi Igor,
> > > >
> > > > yes - but its not mounted to "/*" but to "/" - is it
> > > possible to have
> > > > the homepage mounted on "/*" ? means that this page gets
> > > all path as
> > > > indexedURLparams??
> > > >
> > > > if i mount it to /* he doesnt see it as wildcard but as
> fixed "*"
> > > >
> > > > Regards
> > > >
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> > > > > Gesendet: Sonntag, 12. November 2006 18:39
> > > > > An: wicket-dev@incubator.apache.org
> > > > > Betreff: Re: Severe Bug in Wicket 2 / WICKET-42
> > > > >
> > > > > the homepage is always mounted on /
> > > > >
> > > > > -igor
> > > > >
> > > > >
> > > > > On 11/12/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Johan,
> > > > > >
> > > > > > i checked all - everything is now behaving as expected.
> > > Great Work!
> > > > > >
> > > > > > One question however is still to me - why cant i mount a
> > > > > page to "/" ?
> > > > > >
> > > > > > so i could mount a PageDistribution class there which then
> > > > > handles the
> > > > > > PageParams logic... or would this get in conflict with
> > > the rest
> > > > > > of wicket ?
> > > > > > if so, would it be possible to have a page responsible for
> > > > > every path
> > > > > > behind / but for /wicket/ where the internal could
> be handled ??
> > > > > >
> > > > > > i know this aproach is a bit away from what wicket was
> > > made for...
> > > > > >
> > > > > > Rgards
> > > > > >
> > > > > > > -Ursprüngliche Nachricht-
> > > > > > > Von: Korbinian Bachl [mailto:[EMAIL PROTECTED]
> > > > >
Re: Html dir attribute
This would be the minimal thing to make a RTL language look ok. Japanese for instance is a LTR language (like English and German are). Eelco On 11/13/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: I'm not sure. Isn't it that the whole form / page layout require changes to make it look right. Same is true for japanese etc. That is why we allow for per locale properties file. Juergen On 11/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Hi, > > I converted the form input example this weekend so that it uses one > page and a properties (or xml) file per supported locale. One problem > I have to fix is the fact that Persian (fa IR) is a 'left-to-right' > language (see http://www.i18nguy.com/markup/right-to-left.html). > > Now, it kind of sucks to have to use a separate markup file for just > to insert this tag: > > (or http://www.w3.org/1999/xhtml"; dir="rtl">) > > I was thinking, maybe we could do this automatically. What we could do is this: > * recognize the tags so that we can access them later (much > like we do with the tags now); > * have a getDir or getDirection method in WebPage that works like this: > - If it returns LTR or RTL, a dir attribute is set on the tag; > - if it returns null and the locale is LTR, nothing is done > - if it returns null and the locale is RTL, dir="rtl" is set on > the tag. > > WDYT? > > Eelco >
Re: Html dir attribute
I'm not sure. Isn't it that the whole form / page layout require changes to make it look right. Same is true for japanese etc. That is why we allow for per locale properties file. Juergen On 11/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Hi, I converted the form input example this weekend so that it uses one page and a properties (or xml) file per supported locale. One problem I have to fix is the fact that Persian (fa IR) is a 'left-to-right' language (see http://www.i18nguy.com/markup/right-to-left.html). Now, it kind of sucks to have to use a separate markup file for just to insert this tag: (or http://www.w3.org/1999/xhtml"; dir="rtl">) I was thinking, maybe we could do this automatically. What we could do is this: * recognize the tags so that we can access them later (much like we do with the tags now); * have a getDir or getDirection method in WebPage that works like this: - If it returns LTR or RTL, a dir attribute is set on the tag; - if it returns null and the locale is LTR, nothing is done - if it returns null and the locale is RTL, dir="rtl" is set on the tag. WDYT? Eelco
Re: JIRA as our changes.xml
what about them do you find unreadable? i would be +1 for this. keeping up changes.xml is a pain imho, and since a good amount will already be entered into jira it will take work off us. -igor On 11/13/06, Erik van Oosten <[EMAIL PROTECTED]> wrote: My 2ct: JBoss does this. I find their change reports unreadable. Erik. Martijn Dashorst schreef: > Now that we have a decent infrastructure, we can use JIRA for > generating our changes report. This does mean that we need to do > everything through JIRA: additions, backports, etc. > > Any ideas? > > Martijn > -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Html dir attribute
Hi, I converted the form input example this weekend so that it uses one page and a properties (or xml) file per supported locale. One problem I have to fix is the fact that Persian (fa IR) is a 'left-to-right' language (see http://www.i18nguy.com/markup/right-to-left.html). Now, it kind of sucks to have to use a separate markup file for just to insert this tag: (or http://www.w3.org/1999/xhtml"; dir="rtl">) I was thinking, maybe we could do this automatically. What we could do is this: * recognize the tags so that we can access them later (much like we do with the tags now); * have a getDir or getDirection method in WebPage that works like this: - If it returns LTR or RTL, a dir attribute is set on the tag; - if it returns null and the locale is LTR, nothing is done - if it returns null and the locale is RTL, dir="rtl" is set on the tag. WDYT? Eelco
Re: license headers
I think that is too cumbersome. I'd prefer a really simple solution. Either a one (1) line license header or nothing at all. Based on what I understood from the mailing discussing there doesn't seem to be a clear understanding within Apache if Wicket markup is required to have the license header or not. IMO the markup doesn't contain any (what was the term they used?) intellectual knowledge which needs to be protected. It is the source code that should be protected. But that of course is only my opinion. Juergen On 11/13/06, Frank Bille <[EMAIL PROTECTED]> wrote: On 11/13/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > And it increases memory usage. We might not transfer it to the client > but we cache the markup. > Yes thats right. That sounds like stripping license headers (or replacing with small one-line notices) at build time is the right solution.
Re: JIRA as our changes.xml
My 2ct: JBoss does this. I find their change reports unreadable. Erik. Martijn Dashorst schreef: Now that we have a decent infrastructure, we can use JIRA for generating our changes report. This does mean that we need to do everything through JIRA: additions, backports, etc. Any ideas? Martijn -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
JIRA as our changes.xml
Now that we have a decent infrastructure, we can use JIRA for generating our changes report. This does mean that we need to do everything through JIRA: additions, backports, etc. Any ideas? Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: license headers
On 11/13/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: And it increases memory usage. We might not transfer it to the client but we cache the markup. Yes thats right. That sounds like stripping license headers (or replacing with small one-line notices) at build time is the right solution.
AW: Severe Bug in Wicket 2 / WICKET-42
Yeah similar to that. I mean we currently even cant employ file-endings.
e.g: you can have /page/param/param
but not /page/param/param.html wich would be even more nice and logic (IMHO)
imagine a mount where you could specify "/" as begin and ".htm" as end. ->
you could have 1 handling-class for all data as well as natural URLs (if you
use IndexedURLParams).
if / is solely you could return the start page, if /.htm is called wicket
knows that it would be the handling-class with empty params...so we also
wouldnt crash with any other wicket functionality.
e.g: globalmount(".htm", new IndexedUrlParamStrategy("/",handler.class));
so you also would centralise URLs to just 1 class in app wich then can
delegate to the resulting pages.
was just a thought from what im in now as i need nice URLs and the problems
i stumbled in regarding static content, root etc.
what do you think about this? - i'm interested in any thoughts about it.
Best Regards,
Korbinian
> -Ursprüngliche Nachricht-
> Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 13. November 2006 10:20
> An: wicket-dev@incubator.apache.org
> Betreff: Re: Severe Bug in Wicket 2 / WICKET-42
>
> So this way?
>
> / == home page
> /?p=a == homepage with page params.
> /?interface:xxx == an callback to an existing page
> /?bookmarkablePage=xxx == an none mounted bookmarkable page request
> /input == mounted bookmarkable page
>
> and then
>
> /a == this is not mounted like input above.. Then it should
> go to a page that was mounted on /* ??
> So you want to have a fallback to a page?
>
> johan
>
>
>
> On 11/12/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> >
> > Yeah, that is what i mean -
> >
> > e.g: mount to /*.html -> would mean it goes for /[everything].html
> > wich would introduce even more flexibility...
> >
> > currently, it goes to "/[neededCharacter]" and this catches
> > /[neededCharacter][anythingBehind]
> > e.g: /a ->
> > /a/b is valid
> > /aa/b is valid
> > /a is valid
> >
> > as / is mounted for the homepage and you cant mount a
> wildcard so far,
> > you still need a fixed point you can hook on.
> >
> > Regards
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > Gesendet: Sonntag, 12. November 2006 20:15
> > > An: wicket-dev@incubator.apache.org
> > > Betreff: Re: Severe Bug in Wicket 2 / WICKET-42
> > >
> > > what does a page mounted on /* means in your eyes?
> > > /[everything]??
> > >
> > > there is no such a thing like wild card mounting.
> > >
> > > johan
> > >
> > >
> > > On 11/12/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi Igor,
> > > >
> > > > yes - but its not mounted to "/*" but to "/" - is it
> > > possible to have
> > > > the homepage mounted on "/*" ? means that this page gets
> > > all path as
> > > > indexedURLparams??
> > > >
> > > > if i mount it to /* he doesnt see it as wildcard but as
> fixed "*"
> > > >
> > > > Regards
> > > >
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> > > > > Gesendet: Sonntag, 12. November 2006 18:39
> > > > > An: wicket-dev@incubator.apache.org
> > > > > Betreff: Re: Severe Bug in Wicket 2 / WICKET-42
> > > > >
> > > > > the homepage is always mounted on /
> > > > >
> > > > > -igor
> > > > >
> > > > >
> > > > > On 11/12/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Johan,
> > > > > >
> > > > > > i checked all - everything is now behaving as expected.
> > > Great Work!
> > > > > >
> > > > > > One question however is still to me - why cant i mount a
> > > > > page to "/" ?
> > > > > >
> > > > > > so i could mount a PageDistribution class there which then
> > > > > handles the
> > > > > > PageParams logic... or would this get in conflict with
> > > the rest
> > > > > > of wicket ?
> > > > > > if so, would it be possible to have a page responsible for
> > > > > every path
> > > > > > behind / but for /wicket/ where the internal could
> be handled ??
> > > > > >
> > > > > > i know this aproach is a bit away from what wicket was
> > > made for...
> > > > > >
> > > > > > Rgards
> > > > > >
> > > > > > > -Ursprüngliche Nachricht-
> > > > > > > Von: Korbinian Bachl [mailto:[EMAIL PROTECTED]
> > > > > > > Gesendet: Sonntag, 12. November 2006 10:32
> > > > > > > An: wicket-dev@incubator.apache.org
> > > > > > > Betreff: AW: Severe Bug in Wicket 2 / WICKET-42
> > > > > > >
> > > > > > > Really fast :)
> > > > > > >
> > > > > > > i check it out soon and report,
> > > > > > >
> > > > > > > Regards
> > > > > > >
> > > > > > > > -Ursprüngliche Nachricht-
> > > > > > > > Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > > > > > > Gesendet: Samstag, 11. November 2006 23:17
> > > > > > > > An: wicket-dev@incubator.apache.org
> > > > > > > > Betreff: Re: Severe Bug in Wicket 2 / WICKET-42
> > > > > > > >
> > > > > > > > should be fixed now.
> > > > > > > >
> > > > > > > >
> > > > >
Re: license headers
And it increases memory usage. We might not transfer it to the client but we cache the markup. Juergen On 11/13/06, Frank Bille <[EMAIL PROTECTED]> wrote: But you are right though that we still have that issue with were and if we strip headers. All pages .html (not extended), .css and .js files *will* have the license header and until we come to an agreement between us and ASF they stay. And that sucks IMO Frank On 11/13/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > duh > > -igor > > > On 11/13/06, Frank Bille <[EMAIL PROTECTED]> wrote: > > > > Hmm Will you get it returned? It's a panel so it's only the content of > it > > that gets returned, right? > > > > Frank > > > > On 11/13/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > > > just noticed the below > > > > > > this is a bad joke right? > > > > > > markup: 1line > > > license: 14 lines > > > > > > are we stripping the license block somewhere? or are we sending it to > > the > > > client? > > > > > > you include two ajax editable choices and you get two of these headers > > in > > > the returned markup? > > > > > > -igor > > > > > > > > > Modified: incubator/wicket/trunk/wicket > > > > > > > > > -extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html > > > URL: > > > > > > > > > http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html?view=diff&rev=474183&r1=474182&r2=474183 > > > > > > > > > == > > > --- > > > > > > > > > incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html > > > (original) > > > +++ > > > > > > > > > incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html > > > Mon Nov 13 00:06:17 2006 > > > @@ -1 +1,17 @@ > > > + > > > [label] > > wicket:id="editor"> > > > > > > > > > > > >
Re: Severe Bug in Wicket 2 / WICKET-42
So this way? / == home page /?p=a == homepage with page params. /?interface:xxx == an callback to an existing page /?bookmarkablePage=xxx == an none mounted bookmarkable page request /input == mounted bookmarkable page and then /a == this is not mounted like input above.. Then it should go to a page that was mounted on /* ?? So you want to have a fallback to a page? johan On 11/12/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: Yeah, that is what i mean - e.g: mount to /*.html -> would mean it goes for /[everything].html wich would introduce even more flexibility... currently, it goes to "/[neededCharacter]" and this catches /[neededCharacter][anythingBehind] e.g: /a -> /a/b is valid /aa/b is valid /a is valid as / is mounted for the homepage and you cant mount a wildcard so far, you still need a fixed point you can hook on. Regards > -Ursprüngliche Nachricht- > Von: Johan Compagner [mailto:[EMAIL PROTECTED] > Gesendet: Sonntag, 12. November 2006 20:15 > An: wicket-dev@incubator.apache.org > Betreff: Re: Severe Bug in Wicket 2 / WICKET-42 > > what does a page mounted on /* means in your eyes? > /[everything]?? > > there is no such a thing like wild card mounting. > > johan > > > On 11/12/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: > > > > Hi Igor, > > > > yes - but its not mounted to "/*" but to "/" - is it > possible to have > > the homepage mounted on "/*" ? means that this page gets > all path as > > indexedURLparams?? > > > > if i mount it to /* he doesnt see it as wildcard but as fixed "*" > > > > Regards > > > > > > > -Ursprüngliche Nachricht- > > > Von: Igor Vaynberg [mailto:[EMAIL PROTECTED] > > > Gesendet: Sonntag, 12. November 2006 18:39 > > > An: wicket-dev@incubator.apache.org > > > Betreff: Re: Severe Bug in Wicket 2 / WICKET-42 > > > > > > the homepage is always mounted on / > > > > > > -igor > > > > > > > > > On 11/12/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: > > > > > > > > Johan, > > > > > > > > i checked all - everything is now behaving as expected. > Great Work! > > > > > > > > One question however is still to me - why cant i mount a > > > page to "/" ? > > > > > > > > so i could mount a PageDistribution class there which then > > > handles the > > > > PageParams logic... or would this get in conflict with > the rest > > > > of wicket ? > > > > if so, would it be possible to have a page responsible for > > > every path > > > > behind / but for /wicket/ where the internal could be handled ?? > > > > > > > > i know this aproach is a bit away from what wicket was > made for... > > > > > > > > Rgards > > > > > > > > > -Ursprüngliche Nachricht- > > > > > Von: Korbinian Bachl [mailto:[EMAIL PROTECTED] > > > > > Gesendet: Sonntag, 12. November 2006 10:32 > > > > > An: wicket-dev@incubator.apache.org > > > > > Betreff: AW: Severe Bug in Wicket 2 / WICKET-42 > > > > > > > > > > Really fast :) > > > > > > > > > > i check it out soon and report, > > > > > > > > > > Regards > > > > > > > > > > > -Ursprüngliche Nachricht- > > > > > > Von: Johan Compagner [mailto:[EMAIL PROTECTED] > > > > > > Gesendet: Samstag, 11. November 2006 23:17 > > > > > > An: wicket-dev@incubator.apache.org > > > > > > Betreff: Re: Severe Bug in Wicket 2 / WICKET-42 > > > > > > > > > > > > should be fixed now. > > > > > > > > > > > > > > > > > > On 11/11/06, Korbinian Bachl > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > well, it works if it is: > > > > > > > a, the first access of the WebApp with no provious > > > > > ReDeploy b, the > > > > > > > root is accessed then > > > > > > > > > > > > > > if i redeploy just once, i cant access the root anymore - > > > > > > however the > > > > > > > direct path always works... > > > > > > > if i redeploy it and access the path before, it chains > > > > > > > > > > > > > > another danger thing is that following works: > > > > > > > assume you have IndexedPageParams and index.class mounted > > > > > to /Index: > > > > > > > > > > > > > > if you then access it via /Index/foo/bar/Index/foo2 > > > > > > > > > > > > > > and print out pageparams.toString you only get 0=foo2 , > > > > > meaning he > > > > > > > access it at last point, and not at first! > > > > > > > This violates JEE security !!! > > > > > > > > > > > > > > i also noticed that if you use a servlet and > > > > > > BookMarkablePageLinks the > > > > > > > URLs look like these > 127.0.0.1/?param=value - and > > > > > > mounting > > > > > > > using a servlet was not possible at all > > > > > > > > > > > > > > Best Regards > > > > > > > > > > > > > > Korbinian > > > > > > > > > > > > > > > > > > > > > > -Ursprüngliche Nachricht- > > > > > > > > Von: Johan Compagner [mailto:[EMAIL PROTECTED] > > > > > > > > Gesendet: Samstag, 11. November 2006 17:30 > > > > > > > > An: wicket-dev@incubator.apache.org > > > > > > > > Betreff: Re: Severe Bug in Wicket 2 / WICKET-42 > > > > > > > > > > > > > > > > does it always just work if always your first access is
Re: license headers
But you are right though that we still have that issue with were and if we strip headers. All pages .html (not extended), .css and .js files *will* have the license header and until we come to an agreement between us and ASF they stay. And that sucks IMO Frank On 11/13/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: duh -igor On 11/13/06, Frank Bille <[EMAIL PROTECTED]> wrote: > > Hmm Will you get it returned? It's a panel so it's only the content of it > that gets returned, right? > > Frank > > On 11/13/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > just noticed the below > > > > this is a bad joke right? > > > > markup: 1line > > license: 14 lines > > > > are we stripping the license block somewhere? or are we sending it to > the > > client? > > > > you include two ajax editable choices and you get two of these headers > in > > the returned markup? > > > > -igor > > > > > > Modified: incubator/wicket/trunk/wicket > > > > > -extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html > > URL: > > > > > http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html?view=diff&rev=474183&r1=474182&r2=474183 > > > > > == > > --- > > > > > incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html > > (original) > > +++ > > > > > incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html > > Mon Nov 13 00:06:17 2006 > > @@ -1 +1,17 @@ > > + > > [label] > wicket:id="editor"> > > > > > >
Re: license headers
duh -igor On 11/13/06, Frank Bille <[EMAIL PROTECTED]> wrote: Hmm Will you get it returned? It's a panel so it's only the content of it that gets returned, right? Frank On 11/13/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > just noticed the below > > this is a bad joke right? > > markup: 1line > license: 14 lines > > are we stripping the license block somewhere? or are we sending it to the > client? > > you include two ajax editable choices and you get two of these headers in > the returned markup? > > -igor > > > Modified: incubator/wicket/trunk/wicket > > -extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html > URL: > > http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html?view=diff&rev=474183&r1=474182&r2=474183 > > == > --- > > incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html > (original) > +++ > > incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html > Mon Nov 13 00:06:17 2006 > @@ -1 +1,17 @@ > + > [label] wicket:id="editor"> > >
Re: license headers
Hmm Will you get it returned? It's a panel so it's only the content of it that gets returned, right? Frank On 11/13/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: just noticed the below this is a bad joke right? markup: 1line license: 14 lines are we stripping the license block somewhere? or are we sending it to the client? you include two ajax editable choices and you get two of these headers in the returned markup? -igor Modified: incubator/wicket/trunk/wicket -extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html URL: http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html?view=diff&rev=474183&r1=474182&r2=474183 == --- incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html (original) +++ incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html Mon Nov 13 00:06:17 2006 @@ -1 +1,17 @@ + [label]
license headers
just noticed the below this is a bad joke right? markup: 1line license: 14 lines are we stripping the license block somewhere? or are we sending it to the client? you include two ajax editable choices and you get two of these headers in the returned markup? -igor Modified: incubator/wicket/trunk/wicket -extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html URL: http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html?view=diff&rev=474183&r1=474182&r2=474183 == --- incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html (original) +++ incubator/wicket/trunk/wicket-extensions/src/main/java/wicket/extensions/ajax/markup/html/AjaxEditableChoiceLabel.html Mon Nov 13 00:06:17 2006 @@ -1 +1,17 @@ + [label]
