Tony, Comments in-line...
Tony Drago wrote: > Hi, > > First of all, I promise I'm not trolling. I'm going to say some critical > things about Stripes here, but my intention is to understand whether I'm > missing something, not to offend. If you don't like to read criticism of > your favorite framework, you should probably not read any further. Constructive criticism is great... making people think makes everything / everyone hopefully evolve ;-) > What bugs me about the Stripes approach is that the request parameters and > the model (UserProfile) are not scoped to the relevant handler method. Sure... but nothing stops you from having a class that has only 1 event handler in it. But yes I see your point... . > In most cases, a controller class has more than one handler, and I really > dislike the fact that there's no way to tell just by looking at the code > which request params and view model go with which handler method. On the surface your statement is totally valid and I have to agree. However... you could look at this from at least 2 different angles: 1) If the request params are so different then why put them in the same action bean in the 1st place? Nothing stops you from doing so... but is that good design... perhaps not i.e. any kind of class whether its an action bean or a POJO by definition encapsulates behaviour and attributes... if there are attributes in there that don't totally relate to the behaviour then refactoring might be warranted. 2) On the other hand if the request params are similar... as in cases like for example doing CRUD on a database entity... then I find it to be a non-issue as the action bean deals with the request params it has defined in it. In fact, I find it to be refreshing and clear and eliminates me having to define the params the same over and over again for multiple event handlers. I would suggest you try building some more real world examples / test cases to see if it suits you and in the end if it doesn't then so be it... but these examples are too simplistic to realize any significant pros or cons. > I know you could put each handler in its own class, but that will create a > whole other > set of problems. > As I mentioned if the attributes are really that different perhaps its warranted. But I'm sure you'll have cases it isn't. Test code and documentation is also not out of the question... Right? If you have say for example on a "add" event that the id should not be set or should be passed in as "-" or whatever then you could should test for that and document that in your add event handler. But what other issues are you alluding to? A proliferation of classes? > Fundamentally, having variables which should be scoped to a single method > scoped to a single class, feels like bad OO practice (poor encapsulation). > Am I missing something, or is this just something that most Stripes users > don't care about? > Encapsulation in OO IMHO pertains to the class as a whole not the method level. If you want to encapsulate at the method level then your going to have a hard time not allowing someone to access and affect other attributes of the class (e.g. other attributes) as even if you mark attributes as private any method of the class can alter it. Perhaps you might be used to defining classes that should ideally be further refactored into multiple classes. Not sure - but if you could provide some more complex examples then we could examine specifics and dispense with theory or generalized statements (from my side as well) ;-) HTH, --Nikolaos ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
