Thank you all for your opinion, it helped me decide not to enforce the Passive View pattern here, we had to refactor one component from it back to the wicket way but it didn't do much harm
I know the pattern has been split, and I meant Passive View, it's just that I thought the MVP term is more recognisable. Yes I wanted to use this pattern for design purposes not testability (because it's already there) anyway as the project progresses I will let you know how the codebase looks like and by the way I'll be soon be posting some other questions, this time more concrete and to-the-point, as we've hit the wall while writing one of our custom components regards Wojtek 2008/3/4, Peter Thomas <[EMAIL PROTECTED]>: > On 3/4/08, Ned Collyer <[EMAIL PROTECTED]> wrote: > > > > > > Firstly, I am not familiar with MVP but have used MVC a lot, and had a > > quick > > read over Fowlers stuff. > > > > I never really heard of MVP and looks like as per Martin Fowler's site it > has been "retired" and split into two other esoteric patterns "Supervising > Controller" and "Passive View" > > http://www.martinfowler.com/eaaDev/ModelViewPresenter.html > > > Personally, I like to approach everything "enterprisey" by using services > > which can be split into different areas of functionality. > > > > The interface can be developed in a separate module so you do not have to > > have the web bit influence your "enterprisey" bit. U could expose your > > entire app via different web tier, be it spring mvc, struts, wicket > > whatever. I guess my point is it should not interfere with your overall > > design (sure it will effect your final architecture solution) > > > > What does enterprise mean anyway ;) > > > > I agree with Ned here, as long as you have a well-defined service-layer, you > should be fine. > > > > Now, yesterday we were discussing which approach should we take to > > > developing our application, and we got stuck on the part where didn't > > > know what to choose MVP or the simple way as shown in the wicket > > > books. > > > > > > For simple cases (and components) the simple approach would probably > > > suffice, I'm not so sure it will do us good for the complex components > > > we know we will have to develop. This is because of the mix that we > > > have here of the view and the controller. E.g. when I have a component > > > which allows me to choose a value from a list (not a regular > > > dropdown), and on this list I have a button which enables me to add > > > another value to the list, the list by the way is pagable and sortable > > > (as it may get thousands elements long) so we have to query the DB > > > using ajax. So when I think about such a component in wicket I'm > > > afraid that it will create a unmaintainable mess because I will have > > > web components, their behaviours, calls to services, and possibly > > > anonymous renderers for lists snooping around the domain objects > > > (retrieved from the model). And it scares me. > > > > > > I just want to keep the code it easy to read, comprehend and maintain > > > > > > The approach I would normally take when using e.g. Swing would be to > > > use the MVP pattern or rather the Passive View flavour (by Martin > > > Fowler), in order to have the presenter wire everything. Problem is > > > it's a lot of additional code I will not need for the simple cases, > > > and I don't get the other major benefit of Passive View - testability, > > > because Wicket components are already unit testable (as opposed to > > > Swing). On the other hand I would not like to have half of the app > > > written using one approach and the other half the second. > > > > > > How do you approach such scenarios? Maybe I'm just imagining things, > > > but maybe not, please share > > > > > > > > I quickly read through "Passive View" - and the definition is given as: > > "A screen and components with all application specific behavior extracted > into a controller so that the widgets have their state controlled entirely > by controller" > > And later on in the description "The driving reason to use Passive View is > to enhance testability." > > Most of what I read sounds very abstract and very hard to relate to Wicket > components and models. If you ask my opinion you write all your > presentation logic as part of your Wicket component (or page) which pulls > data from model objects which you normally get from your service-layer. I > feel it will be very hard to introduce a layer that has no dependency on > Wicket - but does all the Wicket work of creating a view. Now if the whole > point is to improve unit testability - it may be a waste of time because as > you yourself pointed out, Wicket components *are* unit testable. Does this > make sense? > > When you worry about unmaintainable code resulting from your use case - I > would suggest you do a quick proof of concept of what you are trying to > explain, and I for one would be interested in hearing how it goes. In this > case I think looking at the code would make much more sense than reading > about patterns :) > > > - Peter. > -- Wojtek Biela --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
