Ted, I finally had a chance to look at your JPA mailreader.
I know this was in the original, but I really don't like the way that they have most of the functionality for the actions is in a superclass. To me, that's hiding functionality. (Especially when the domain model is in the super class) And this become problematic on bigger projects. Do you have multiple superclasses to extend from with different domain models? What if you need functionality from 2 different superclasses. At a certain size of project this technique breaks down and it irritates me that the standard example shows it this way.
I also don't like having a separate create vs. update action. My general rule of thumb is: if the domain model is the same and the use cases are closely related, it should be the same action. I don't generally combine list and edit actions, but the create/edit/save functionality will all be in one class as would be the list/paging/sort use cases.
Why are the name queries on the domain object? I don't dislike it, I'm just curious about why you took that approach.
I think the validation annotations are ugly and hard to read, but others may disagree. I do like how grails uses enclosures to capture that information, can you convert this example to grails? :)
I'm not a fan of having a separate interface for the Manager classes, just for the sake of having an interface. If it's unlikely that there will ever be another implementation, then it should just be a class. One argument you could make is: "Well what if you switch data storage technologies?" Well, we just did that in this example and the interfaces had to be redesigned, so did they really buy you anything?
Again I cringe at seeing a superclass for all domain objects. I think it makes sense for the managers to have a superclass though. In my experience with big projects, having a superclass for domain objects doesn't make a lot of sense.
I hope I haven't been too brutal with my comments. :) I'm so glad we finally have a mailreader example that uses JPA. A lot of what you see here is my experience from working with webwork on a large (200+ action) project. There's lots of things that seem fine on a small scale, but when you have to scale up to that size, lots of things become problematic. I'd also be curious to find out how others have structured larger projects in webwork/struts. I think that's helpful because we spent a lot of time reinventing the wheel when it comes to large project best practices.
Tom Ted Husted wrote:
The work-in-progress is checked into the sandbox now. * http://svn.apache.org/viewvc/struts/sandbox/trunk/jpa-mailreader/ I'll track further work through https://issues.apache.org/struts/browse/WW-1399 This is still very much a prototype, and I would gladly receive any suggestions. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
