Wow. After a flurry of research into this area, i've whipped together
a hibernate/wicket behavior that reads annotations and helps configure
the wicket component respectively.
http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/
Essentially, right now
can these methods be made public?
AbstractPropertyModel#propertyExpression
AbstractPropertyModel#propertyType
I'm open to suggestions, but what I'm trying to do is build a behavior
that inspects the model to attach client side validation. I'm trying
to extract the PropertyModel expression to loo
thanks!
stefan
> -Original Message-
> From: Eelco Hillenius [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 08, 2007 10:50 PM
> To: wicket-dev@incubator.apache.org
> Subject: Re: APP_CLASS_PARAM not static in
> ContextParamWebApplicationFactory?
>
>
> But then there is
>
>
Done.
Eelco
> > it would be nice it the variable APP_CLASS_PARAM in class
> >
> > org.apache.wicket.protocol.http.ContextParamWebApplicationFactory
> >
> > can be marked as static, so it is easy to reference them when initializing
the wicket servlet via code.
> > for now, it is marked as pub
Ugh. Strike that comment. I misread.
Eelco
On 5/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
But then there is
final String applicationClassName =
filter.getFilterConfig().getInitParameter(
APP_CLASS_PARAM);
I don't know why that has to be
But then there is
final String applicationClassName =
filter.getFilterConfig().getInitParameter(
APP_CLASS_PARAM);
I don't know why that has to be flexible though. Looks like bloat to
me. Also, upper case should be for statics, so it's use here is
hello.
it would be nice it the variable APP_CLASS_PARAM in class
org.apache.wicket.protocol.http.ContextParamWebApplicationFactory
can be marked as static, so it is easy to reference them when initializing the
wicket servlet via code.
for now, it is marked as public and final, but not static.
ahh yes that behavior did work perfeclty!
On 5/8/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
It's not. setFocusOnId just sets a javascript variable. It doesn't
really set focus. What i wanted to do was to reset set the javascript
variable to null.
It does make sense.
-Matej
On 5/8/07, Johan
It's not. setFocusOnId just sets a javascript variable. It doesn't
really set focus. What i wanted to do was to reset set the javascript
variable to null.
It does make sense.
-Matej
On 5/8/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
ahh
stupid stupid stupid :)
but why do this:
fin
ahh
stupid stupid stupid :)
but why do this:
final String id = component != null ? component.getMarkupId() : null;
appendJavascript("Wicket.Focus.setFocusOnId('" + id + "');");
instead of
if (component != null)
appendJavascript("Wicket.Focus.setFocusOnId('" +
com
It was me. You code didn't allow null component, i needed to disable
setting focus, so i changed the code. But i didn't notice that i
always pass null to javascript ;-)
-Matej
On 5/8/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
only this time i think it was not you!
It has to be me i think..
only this time i think it was not you!
It has to be me i think.. But how on earth that could pass me is beyond me
because i do use that code! and i have here servoy solutions where i
demonstrated requestFocus!
very very strange..
On 5/8/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
has, it was
yeah that stupid AJAX soccer team!
PSV!
johan
On 5/8/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
what will people think??? :)
http://papernapkin.org/pastebin/view/5915
-igor
On 5/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Author: jcompagner
> Date: Tue May 8 07:44:07 2007
>
done
On 5/8/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote:
Johan Compagner wrote:
>
> onBeforeRender call moved a few lines above
> So that it is on the same place onAttach() was
> So before the authorization check
>
> johan
>
Yes, I saw that in the code. Thanks a lot.
But can it be changed in
Thanks. I'll fix it on our side for the moment.
I will keep reporting things I come across while backporting. Hope it's not
only harrassing on the core developers. Somehow I try to contribute by
pointing out possible bugs or missing things.
Please keep on harrassing. That's the way we keep impr
Thanks. I'll fix it on our side for the moment.
I will keep reporting things I come across while backporting. Hope it's not
only harrassing on the core developers. Somehow I try to contribute by
pointing out possible bugs or missing things.
Jan.
--
View this message in context:
http://www.nabb
Ryan, lets finish this thread and move on to gTalk and *talk* about this.
I'm adding you right now.
Or even better... why don't you guys join the ##wicket IRC channel on
freenode.net? It's perfect for discussions like that, and changes are
you'll get some more people opinions in the process (44
It would be good to open up a JIRA issue for that if you plan to work
on that, Juergen.
Cheers,
Eelco
On 5/8/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
It'll take some time. It was not an easy thing to do and the some
details of the approach we took needs to be reworked. But we'll get
t
It'll take some time. It was not an easy thing to do and the some
details of the approach we took needs to be reworked. But we'll get
there. Not sure it'll make it into 1.3 though.
Juergen
On 5/8/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote:
Are there any plans for backporting this ?
Jan.
--
V
Ryan, lets finish this thread and move on to gTalk and *talk* about this.
I'm adding you right now.
No, I dont have an account yet, and yes you can start the project in
wicket-stuff and after that, I'll ask you for permission. What'd you think?
[]' s
--
Bruno Borges
Summa Technologies Inc.
www.s
At least he admits to mistakes, if a bit roughly.
On Tue, 2007-05-08 at 09:40 -0700, Igor Vaynberg wrote:
> what will people think??? :)
>
> http://papernapkin.org/pastebin/view/5915
>
> -igor
>
>
> On 5/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > Author: jcompagner
> > Date: T
has, it was just one my commit that has upset him. I'm pretty sure the
"stupid stupid stupid stupid was a message for me :)
-Matej
On 5/8/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
what will people think??? :)
http://papernapkin.org/pastebin/view/5915
-igor
On 5/8/07, [EMAIL PROTECTED] <[
Johan Compagner wrote:
>
> onBeforeRender call moved a few lines above
> So that it is on the same place onAttach() was
> So before the authorization check
>
> johan
>
Yes, I saw that in the code. Thanks a lot.
But can it be changed in Component:renderComponent() too ?
Jan.
--
View this me
what will people think??? :)
http://papernapkin.org/pastebin/view/5915
-igor
On 5/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: jcompagner
Date: Tue May 8 07:44:07 2007
New Revision: 536209
URL: http://svn.apache.org/viewvc?view=rev&rev=536209
Log:
stupid stupid stupid stupid.
Hey Bruno, I'd love to contribute. My experience with annotations and
hibernate validators is very limited, but I'd love to dig in. do you
have any place to start for source code? I'd like to start a small
project in wicket-stuff to try this out. do you have account setup
for wicket-stuff acce
Johan Compagner wrote:
>
> i moved it up (where attach was)
>
I see, you changed it in Page.
Can it be changed in Component:renderComponent() too ? (counterpart for ajax
rendering)
Jan.
--
View this message in context:
http://www.nabble.com/Backporting-from-2.0%3A-onAttach%28%29-or-beforeRe
onBeforeRender call moved a few lines above
So that it is on the same place onAttach() was
So before the authorization check
johan
On 5/8/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote:
Johan Compagner wrote:
>
> i moved it up (where attach was)
>
Sorry, can you explain a bit ? What did you m
Johan Compagner wrote:
>
> i moved it up (where attach was)
>
Sorry, can you explain a bit ? What did you move up ?
Jan.
--
View this message in context:
http://www.nabble.com/Backporting-from-2.0%3A-onAttach%28%29-or-beforeRender%28%29---tf3710300.html#a10378315
Sent from the Wicket - Dev
i moved it up (where attach was)
On 5/8/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote:
In the former 2.0, we created components within a repeater in the
onAttach()
method (during rendering, no changes to the component graph were allowed).
And as I see, that's also what the Wicket ListView did.
In the former 2.0, we created components within a repeater in the onAttach()
method (during rendering, no changes to the component graph were allowed).
And as I see, that's also what the Wicket ListView did.
In the current trunk, things have changed, so we can no longer create these
components in
I need access to the exception that caused the internal error, and if
that can be done trough InternalErrorPage, then that's fine by me.
Instead of using this constructor reflection magic, maybe a simple
factory interface can be defined that can create pages. So instead of
having a setInternalErr
if we find a nice api for this fine by me.
johan
On 5/8/07, Bart Molenkamp <[EMAIL PROTECTED]> wrote:
I need access to the exception that caused the internal error, and if
that can be done trough InternalErrorPage, then that's fine by me.
Instead of using this constructor reflection magic, m
Ryan, want to work together on this?
Regards,
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
I think someone (you?) just has to take up the initiative. I think the
core team is too tight up atm.
Ee
I need access to the exception that caused the internal error, and if
that can be done trough InternalErrorPage, then that's fine by me.
Instead of using this constructor reflection magic, maybe a simple
factory interface can be defined that can create pages. So instead of
having a setInternal
Thanks!
Martijn
On 5/7/07, Philip A. Chapman <[EMAIL PROTECTED]> wrote:
Guys,
Since wicket now uses slf4j, I've changed datepicker to use slf4j now too.
The maven pom for datepicker was counting on the wicket dependency to bring
in commons-logging.
Thanks,
--
Philip A. Chapman
Desktop
ahh but this is not about our own ExceptionPage but more about
the InternalPage should be a bit better.
Why not look if that page has a Exception constructor param give it to it?
The problem i can see maybe is that we do a redirect to it.. (but i am not
sure)
johan
On 5/8/07, Eelco Hillenius
I think someone (you?) just has to take up the initiative. I think the
core team is too tight up atm.
Eelco
On 5/8/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
I haven't heard anything on this thread for a while, and it seemed
really exciting. Has there been any progress on creating a wicket
va
I don't agree with that though. We (at Teachscape) are using the
override as using the setting is just too simplistic. Imho an example
of where convenience won from a better approach.
This is what we do:
public Page onRuntimeException(Page page, RuntimeException e) {
if
I haven't heard anything on this thread for a while, and it seemed
really exciting. Has there been any progress on creating a wicket
validator that uses hibernate annotations? anything available in
wicket-stuff to take a look at?
On 4/25/07, Xavier Hanin <[EMAIL PROTECTED]> wrote:
On 4/25/07,
in production you shouldn't give users exceptions
then they know exactly what you run and then it is much easier to try to
hack something
exception in in production environments should be get from the log.
So you could set your own InternalError page create an extra log entry with
more info (cur
I didn't know it was just there for debugging. I think it is useful for
production as well because it shows a stacktrace (and the
InternalErrorPage can't show it).
Is there any way to access the exception from an internal error page? If
so then InternalErrorPage is good for me too.
Bart.
Johan
I think we had that method on application but that was moved again.
But why do you want to change the ExceptionErrorPage?
That is just there for debugging, Normally in production you would see the
InternalErrorPage
that can be set through the settings.
johan
On 5/8/07, Bart Molenkamp <[EMAIL P
Yeah, it was a nice idea, though I've never used it. Maybe Jonathan is
interested in reviving it.
Eelco
On 5/8/07, Mats Norén <[EMAIL PROTECTED]> wrote:
I understand, just thought the idea was too cool to just discard. :)
/M
On 5/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> Only at sou
I understand, just thought the idea was too cool to just discard. :)
/M
On 5/8/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Only at sourceforge somewhere. The main problems with it are that
Jonathan doesn't feel like maintaining the project, and that it uses
NetBeans code with an incompatible
Only at sourceforge somewhere. The main problems with it are that
Jonathan doesn't feel like maintaining the project, and that it uses
NetBeans code with an incompatible license. It might be resurrected as
a wicket-stuff project if someone wants to take it up. Maybe Jonathan
can say about this a b
What ever happened to the Sprocket idea?
Is the code still available somewhere?
/M
Hi,
I think it's currently too hard to show a custom exception page. To do
so, I need to override Application.getRequestCycleFactory(), return my
own IRequestCycleFactory implementation, that can build my subclass of
WebRequestCycle that overrides the onRuntimeException() method.
Maybe it's
And if it is really a great concern, people can implement their own
strategy that e.g. works on UUIDs or such. That'd be impossible to
guess.
Eelco
On 5/8/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
WebUrlCompressing is random but only it is "stable" if you walk to that page
with that form
e
[x] Yes, propose Wicket for Graduation
[ ] No, Wicket is not ready to graduate
Al (sorry, been away for a couple of days).
WebUrlCompressing is random but only it is "stable" if you walk to that page
with that form
exactly the same way in all your new sessions.
But because it is session relative that user first have to go to that page
(because it has to exists)
then to another site that then guess the exact same thin
Are there any plans for backporting this ?
Jan.
--
View this message in context:
http://www.nabble.com/Backporting-from-2.0%3A-renderComponent%28%29-fails-if-there-is-no-markup-tf3703472.html#a10370932
Sent from the Wicket - Dev mailing list archive at Nabble.com.
51 matches
Mail list logo
