RE: Wicket at ApacheCon EU'09 in Amsterdam

[cpopetz]

As the programmer currently maintaining/improving the seam/wicket
integration:

(a) I recently got a change to wicket from Igor in less than a day, upon
request, to support this integration.  I doubt I would have had as much luck
if the behavior of wicket was in a JSR, but in any case, the lack of a JSR
didn't hinder me.

(b) I've coded things to JSR specs before, and found it no easier (and often
less) than reading wicket's source, which is very well commented, and asking
questions.  The ability to target a technology for integration is not about
whether it's "standardized."

(c) I won't comment on the "why" of Seam turning into WebBeans using JSR,
but having been on the WebBeans mailing list for a while, I don't think I
would ever volunteer to shepherd anything through that process.  It was
dreadful, slow, and a lot of compromises were made that IMHO had no
technical merit and were completely politically motivated.

-Clint


whoover wrote:
> 
> That is a good point... That is the very reason why they are now trying
> to push WebBeans as part of the standard profile ;o)
> 
> -Original Message-
> From: Oleg Taranenko [mailto:taranenko.for...@googlemail.com] 
> Sent: Friday, February 13, 2009 4:05 PM
> To: users@wicket.apache.org
> Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam
> 
> Hmm...
> 
> some time ago (approx 1,5 year ) was attempts to marry JBoss Seam and
> Wicket. Was it successful? May be this is an example, why wicket should
> to be treated as a standard?
> 
> Oleg
> 
> On Fri, Feb 13, 2009 at 4:59 PM, Hoover, William
> wrote:
> 
>> First of all, thank you for entertaining this idea :o)
>>
>> See comments below...
>>
>> -Original Message-
>> From: Johan Compagner [mailto:jcompag...@gmail.com]
>> Sent: Friday, February 13, 2009 9:38 AM
>> To: users@wicket.apache.org
>> Subject: Re: Wicket at ApacheCon EU'09 in Amsterdam
>>
>> >
>> > From a developers point-of-view standardization can often be a thorn
> 
>> > in our side, but for management it can offer a 
>> > vendor-independent/implementation-independent solution.
>> > Maintaining/upgrading infrastructure is difficult, expensive and 
>> > time consuming. From the point-of-view of management a standard can 
>> > often minimize the risk of vender lock-in.
>>
>>
>>
>> But the examples you gave me have multiply implementations. But wicket
> 
>> doesnt have multiply implementations, what would that mean?
>> That we have IComponent, IRequestCycle, ISession and IApplication and 
>> so on?
>> And that IBM would make its own implementation of all the components 
>> including the base? And JBoss and X and Y?
>>
>> Answer: They do not have multiple implementations now, but they could 
>> potentially have them in the future. It would mean that other 
>> communities could follow a standard and mangement could be satisfied 
>> that Wicket has the backing of a recognized standard.
>>
>> There is no vendor locking for wicket.. (and all other open source web
> 
>> frameworks by the way) what is the locking?
>>
>> Answer: I agree that other frameworks that have a standard have been 
>> disastrous as far as portability between implementations (such as the 
>> loosly organized JSF specification), but the locking I'm referring to 
>> is in realation to the vendor (Wicket in this case) from a business 
>> standpoint. I for one do not have an issue with being tightly coupled 
>> to Wicket, but I can see why managment may have an issue with it. A 
>> question we need to ask ourselves from a management standpoit is if 
>> for whatever reason we had to migrate from Wicket to another 
>> framework, what revenue impact would that have on our organization in 
>> doing so? If we chose a standards base solution would this minimize 
>> the risk due to multiple vendor offerings?
>>
>> And wicket runs pretty much on all simple servlet containers.. Some 
>> bugs in some not counting...
>> So give me a concreet example what a standardized wicket would look 
>> like.
>> What vendor-independent/implementation-independent solutions there 
>> would be then..
>>
>> Answer: This is a preliminary concept, but the Swing-like architecture
> 
>> for the web could be a starting point?
>>
>>
>> >
>> > Another thing to consider is that a broader multi-community 
>> > involvement could also bread innovation. There may be other 
>> > innovators
>>
>> > from other communities that may have valuable input that could 
>> > improve
>>
>> > Wicket in ways that may have not been previously considered. IMHO, 
>> > the
>>
>> > biggest argument for JSR/JCP is that there is often a broader
>> involvement in the process.
>> > Hibernate, for instance, was in a similar position a few years back 
>> > when they introduced a new persistence concept. They have since 
>> > become
>>
>> > heavily involved in the JPA specification process. When I first 
>> > worked
>>
>> > with Hibernate, like many, I was very impressed (similar to the 
>> > first time I worked with Wicket :o), but looking ba

Re: Proper hook for conversational state that also works with tests

[cpopetz]

Thanks Igor, I created https://issues.apache.org/jira/browse/WICKET-2090


igor.vaynberg wrote:
> 
> the problem is wicket tester doesnt run wicket through the entire
> web-request workflow and you are hooking into a part that is not being
> hit. i have a good idea of where to add an extension point, please
> open a jira issue so i can attach a patch there and you can see if it
> will work for you.
> 
> -igor
> 
-- 
View this message in context: 
http://www.nabble.com/Proper-hook-for-conversational-state-that-also-works-with-tests-tp21876375p21911364.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Proper hook for conversational state that also works with tests

[cpopetz]

Hi,

I'm currently responsible for maintaining the Seam/Wicket integration for
the Seam team.  Seam maintains a "conversational" context, a session-based
map that is keyed by an id associated with a set of requests.  Previously
the wicket integration worked by wrapping every redirect or outgoing url and
adding the conversation id as a parameter, and then restoring the
conversation based on that parameter in a servlet filter.  While this works,
it's ugly, and doesn't play with with various URL coding strategies.  

So instead, I've been working on storing the conversational id in Page
metadata.  I did this by providing a new WebRequestCycleProcessor subclass
which in resolve() looks for IPageRequestTarget or
BookmarkablePageRequestTarget, pulls the page out, and restores the
conversation if the parameter is present in metdata.  Correspondingly, in
respond(), I do the inverse.  

This works great when running in-container, but isn't playing well with
tests that use ajax.  When an ajax link is clicked in-container, the full
request cycle is step()ed through.  But BaseWicketTester.clickLink(), which
I presume is the appropriate thing to use, does:

AjaxLink link = (AjaxLink)linkComponent;

setupRequestAndResponse(true);
WebRequestCycle requestCycle = createRequestCycle();
callOnBeginRequest(requestCycle);
AjaxRequestTarget target = new 
AjaxRequestTarget(link.getPage());
requestCycle.setRequestTarget(target);

link.onClick(target);

// process the request target
processRequestCycle(requestCycle);


This means that the link's onClick method is called before my request cycle
hooks have a chance to restore conversational state.  

Is there an alternate way I should be hooking into wicket so that I can
reliably intercept requests to pages and retrieve/store metadata?

Thank you,
-Clint
-- 
View this message in context: 
http://www.nabble.com/Proper-hook-for-conversational-state-that-also-works-with-tests-tp21876375p21876375.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org