Re: [seam-dev] Wicket integration work
Hi Clint,
On 17 Oct 2008, at 19:59, Clint Popetz wrote:
Greetings,
I've been working on wicket integration, and I have a number of
things done that I'd like to contirbute:
* An ant task to instrument wicket components at build time
* Fixes to make it possible to hot-deploy wicket components that
have been instrumented by that task.
Yup, we should definitely support this :-)
* Fixes to problems surrounding inheritance and wicket components.
(Currently if you try to inherit one wicket component from
another, and seam tries to instrument both, you'll hit lots of
problems. The fixes are both in how the components are instrumented
and how WicketComponent/WicketHandler function.)
Hmm, I didn't try that, nice catch.
* Fixes to make it possible for jsf, wicket, and other web tier
components (i.e. struts, using ContextFilter) to co-exist in the
same deployment, which is a requirement of ours.
Interesting one.
I'd like to know how you suggest I go about submitting all this.
Should I create jira issues for each, and then attach the patches to
each?
This is the easiest way for us to process them as we can clearly see
what you are trying to do. You should be able to establish an order in
which the patches should be applied, just note that in the JIRA issues.
Many are entangled, so I can do this, but it will be harder for me,
and harder for whomever integrates, as the patches will collide.
For the last one (jsf/wicket co-existence) I'd like to have a
discussion on best practice. The current approach of having things
like WicketExceptionFilter, WicketManager, and WicketStatusMessages
override the defaults if they are present, based on class
dependencies, obviously doesn't work for the above goal. Some sort
of architecture is needed to use the correct component based on the
type of request, which means we need someone to say "whose request
is this?" Should that discussion happen on this list, or through
jira issue comments?
We don't currently have any ability to do anything other than per-
application selection of components. Have that discussion here I think.
Also, with regard to the ant task, I don't know how you want that
packaged. Is the plan to keep the just-in-time instrumentation of
WEB-INF/wicket (which isn't hot-deployment-compatible) as an option,
with build time instrumentation as the default (i.e. the default in
seam-gen'd build files?)
I don't see why we need to make either the default, both approaches
can coexist I think. It sounds like you want to add Wicket support to
seam-gen?
Or get rid of the just-in-time thing? Currently I have
JavassistInstrumentor extending extending org.apache.tools.ant.Task,
but I have it in a separate project to build the task jar. It also
could remain in jboss-seam.jar.
I think the ant task should go in it's own JAR.
Thanks for the work!
I'm very happy with the results. JSF/RichFaces has unfortunately
been a nightmare for us in terms of maintainability, testability,
and general bugginess, butI didn't want to dump seam's contextual
model, security support, and event support in order to move to
Wicket. I'm very glad I don't have to do so :)
Thanks,
-Clint
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev