Feature Requests item #1543728, was opened at 2006-08-21 04:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1543728&group_id=119783
Please note that this message will contain
The rememberMe functionality in login screens does not longer work;
check the examples. I checked the CookieValuePersister which seems to
work fine. The issue seems to be that onSubmit is not automatically
called.
Juergen
-
U
Hi guys,
How are we doing on models for 2.0? Is it getting stable? Can I start
writing about them? Or are there a couple of things on the todo list
still?
Eelco
-
Using Tomcat but need to do more? Need to support web service
+1
-Igor
On 8/20/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> We should have:>> /trunk <- 2.0> /branches/wicket-1.2 <- 1.2> /releases/wicket-1.2.0> /releases/wicket-1.2.1> /releases/wicket-1.2.2That makes sense to me: +1 on that.
Eelco---
TagModifyingContainer but the longer you make the less appeal it has :)
-Igor
On 8/20/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
TagModifierContainer ;)On 8/20/06, Eelco Hillenius <
[EMAIL PROTECTED]> wrote:
> the counter point being that you are adding components to a TagModifier -> which is
I do agree with Johan's point.
...onSubmit()
{
getRequestCycle().setResponsePage(new MyPage());
}
May be onSubmit is an exception as I don't feel similar about
Session.get() and Application.get()
Juergen
On 8/20/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> >
> > getRequestCycle().setRes
TagModifierContainer ;)On 8/20/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> the counter point being that you are adding components to a TagModifier -> which is a bit weird since TagModifier doesnt really communicate its a> container, but that is the common usecase here right?
You have a point t
also +1 for meand this sandbox approache:/sandbox/ajax_tryoutOn 8/20/06, Eelco Hillenius <
[EMAIL PROTECTED]> wrote:> We should have:>> /trunk <-
2.0> /branches/wicket-1.2 <- 1.2> /releases/wicket-1.2.0> /releases/wicket-1.2.1> /releases/wicket-1.2.2That makes sense to me: +1 on that.Eelco
>
> getRequestCycle().setResponsePage(new MyPage());
>
> is i think much better then saying
>
> RequestCycle.get().setResponsePage(new MyPage());
>
>
> in the first you are saying. Component get your request cycle where you
> belong to.
>
> in the latter you just take something completely out of th
> I don't 'get' what someone will possibly understand better from having
> getRequestCycle() everywhere in the Java class. If it is a problem of
> understanding, then we need some serious extra documentation.
>
> And while you're at it, why not remove getRequestCycle() and
> getSession() also? Requ
You have a point here.
-Matej
Johan Compagner wrote:
> i agree. But in a onSubmit or onClick having to do that is shouldn't be
> needed
>
> then
>
> getRequestCycle().setResponsePage(new MyPage());
>
> is i think much better then saying
>
> RequestCycle.get().setResponsePage(new MyPage());
>
> the counter point being that you are adding components to a TagModifier -
> which is a bit weird since TagModifier doesnt really communicate its a
> container, but that is the common usecase here right?
You have a point there...
Eelco
---
> We should have:
>
> /trunk <- 2.0
> /branches/wicket-1.2 <- 1.2
> /releases/wicket-1.2.0
> /releases/wicket-1.2.1
> /releases/wicket-1.2.2
That makes sense to me: +1 on that.
Eelco
-
Using Tomcat but need to do more? Need
Frank Bille wrote:
> +1
>
> Could it be an idea to create a "release" next to branches for the
> branches/WICKET_1_2_2 instead?
I agree with this. Basically, while svn doesn't distinguish between a
'branch' and a 'tag', we can do so through naming conventions.
We should have:
/trunk <- 2.0
/bra
Hmm, I'm not really sure about much of this, to be honest...
(a) I'm not sure that we should be equating 1.x development with 2.0
development, i.e. I think the /trunk/wicket-[12].x is a bad move.
(b) I *really* don't like the idea of tags for a particular version
being something other than taggin
+1Could it be an idea to create a "release" next to branches for the branches/WICKET_1_2_2 instead? FrankOn 8/20/06, Martijn Dashorst
<[EMAIL PROTECTED]> wrote:
There has been some confusion on the branches and Wicket 1.xdevelopment. This document proposes a solution to this confusion, andasks for
getSharedResouces().add("myimage", new XxxxResource());
you dont have to preregister static resources as of wicket 1.2.1.-Igor
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly w
Only by having such a thing with the naming you can better read the code so you know what it does.
the counter point being that you are adding components to a TagModifier - which is a bit weird since TagModifier doesnt really communicate its a container, but that is the common usecase here right?
-
We do, yet I don't see what's wrong on Session.get() and RequestCycle.get().
These are universal and accessible from every place assuming wicket
request is being processed.
-Matej
Johan Compagner wrote:
> no not hiding in a sense of make them private or something
> But more in a sense that deve
no not hiding in a sense of make them private or somethingBut more in a sense that developers don't have to call that normally.We hide the static access and the usage of a thread local for normal use.johan
On 8/20/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
Which ones? RequestCycle.get() and Session
Which ones? RequestCycle.get() and Session.get()? Don't you dare to hide
those! :-)
-Matej
Johan Compagner wrote:
> ohh forgot to mention. I don't like static access methods. Those if
> needed (for threadlocals)
> should be hidden as possible.
>
> johan
>
>
> On 8/20/06, * Johan Compagner* <
ohh forgot to mention. I don't like static access methods. Those if needed (for threadlocals)should be hidden as possible.johanOn 8/20/06,
Johan Compagner <[EMAIL PROTECTED]> wrote:
No we should hide the thread local access. That is prefectly fine.It is much more clear that all the things you do y
No we should hide the thread local access. That is prefectly fine.It is much more clear that all the things you do you do not on the component but on the request cycle.It just makes much more sense. just some setResponsePage() somewhere in the code in a component. What is that
why call that on the
I dont know about thisWhere will 1.3 reside? and 2.1 ? or 3.x ?(or better said 2.0 when we have released it)1.2 is just a a branch in my eyes. Ok not really a maintenance branch but something more.
But it is in my eyes still a branchI just like thistrunk == wicket X (the last wicket where we work
+1 May be we should restructure wicket-stuff too?On 20.8.2006, at 16.15, Martijn Dashorst wrote:There has been some confusion on the branches and Wicket 1.xdevelopment. This document proposes a solution to this confusion, andasks for a vote on structure. But first a short analysis of theproblems at
There has been some confusion on the branches and Wicket 1.x
development. This document proposes a solution to this confusion, and
asks for a vote on structure. But first a short analysis of the
problems at hand.
According to me, the root cause of this confusion is that we have
effectively two mai
Bugs item #1543456, was opened at 2006-08-20 12:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=684975&aid=1543456&group_id=119783
Please note that this message will contain a full copy
I think that Delegate is an appropiate pattern here, which is used in
much of the convenience methods. One of the biggest problems Java is
facing is the verbosity of the language. Removing these delegating
methods will make reading the application methods a lot less clear.
I don't 'get' what some
See for an example the FormInputApplication in wicket examples.But the simple thing is in the init of your app:getSharedResouces().add("myimage", new XxxxResource());and thenImageButton("mybutton', new ResourceReference("myimage"))
johanOn 8/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]
> wrote:Hi ,c
yes the conversion exception is catched by the convert method of the form component.And then the form component handles this by adding an error (for the feedback panel)We should improve the javadoc of IConverter.convert
so that it tells us what exceptions could be thrownOr make ConversionException
+ for puttin it into coreIt falls under the category like StatelessLink/Form which also users can easily create themselfs.Only by having such a thing with the naming you can better read the code so you know what it does.
johanOn 8/20/06, Jonathan Locke <[EMAIL PROTECTED]> wrote:
based on the fact t
+1 for me to backportSo when upgrading the cookies are one time invalid and not recognized? That doesn't seem to bad for me. If it really does fix problems for some languagesjohan
On 8/20/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
Related to: [ 1531861 ] CookieValuePersister support more enc
Related to: [ 1531861 ] CookieValuePersister support more encoding
Q:"As RFC 2109 defined, cookie only supports ASCII code.
Current implementation of CookieValuePersister
(wicket 1.2.0) does not encode cookie value as ASCII
String. Thus value persistent of FormComponent
does not work properly when
33 matches
Mail list logo
