[seam-dev] Re: Wicket integration work

On Fri, Oct 17, 2008 at 1:59 PM, Clint Popetz <cpopetz(a)gmail.com&gt; wrote: Per Pete's suggestion, I'm starting a discussion on how to do this. There are four classes that currently prevent this from working: * WicketRedirectFilter and WicketExceptionFilter These exist mainly to turn off those two filters for wicket requests. I suggest that these can be deleted, and wicket users can just do: <web:redirect-filter url-pattern="*.seam"/> <web:exception-filter url-pattern="*.seam"/> so that the filters are only enabled for faces-specific requests. That violates DRY, because they have to change that if they change web.xml's mapping of the faces servlet. But I know of no good way from a filter to figure out at runtime how the faces servlet is mapped. * WicketStatusMessages and WicketManager These are more difficult. The hack I did, which works, is to have each extend the faces variants of these classes, and to have each short-circuit the direct super class behavior when org.apache.wicket.Application..exists() returns true, i.e. when wicket has decided it owns the request. But that's ugly, and wouldn't be sustainable as more view layer options are added. FacesManager really shouldn't subclass Manager, in my opinion. It overrides hardly any methods, and the ones it does override only exist in the base class for the benefit of other code which could directly call FacesManager, because it is already faces-aware. I made a stab at seeing what it would take to refactor this to make Manager a view-layer-agnostic component. It's possible, and not even that hard, but the main problem are redirects. Currently a lot of code tells the conversation (or conversation entry) to redirect(), and they both store a jsf view id and then ask the manager to redirect to that id. Since there is only one manager, that manager has to be faces aware. We could instead have conversation subclasses for each view technology, i.e. FacesConversation, and FacesConversationEntry, and create the right one with factories, and have each know how to redirect, or know which component (FacesManager) to ask to redirect. But then we come to the question of "should conversations themselves be view-agnostic," e.g. should it be possible to move from a wicket-based page to a jsf based page while maintaining the same conversation. I think so. But that would mean a fair amount of work, because it means having conversations have two components, a view-agnostic part and a view-centric part, with each delegating to the other. At this point, I feel like I might be treading into deep waters, and so I'm interested in whether this type of work, to make the core of seam less dependent on JSF, is a direction you'd like to see the source go. I don't think it can be done without breaking a fair amount of code, and who knows how much code has EL expressions that reference these components, i.e. to do conversation-switching from JSF. (Ironically, untyped EL expressions breaking due to refactoring is the main reason I'm switching from JSF to wicket :) Thanks for listening, and interested in your thoughts. -Clint