On 7/19/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> This makes sense, but doesn't scale to cases where a particular demo uses > more than one service library of some sort. I'd suggest we put the things > like domain object libraries either at the same level as apps, or in the > sandbox (since they typically will not have any Shale dependencies). What do you more then one service library?
Lets assume you have set up a JPA persistence unit with its associated entity classes for a particular database ... this is the sort of thing that would go at the top level of your proposed directory structure (with the webapps that use it in subdirectories). Now, assume you have a different persistence unit for a different database, and now you need to write a sample app that uses both libraries. Which top level directory do you put the webapp underneath? My thinking was that the
service interfaces only would be shared with the child applications. All child applications would do the exact same thing but with variations on the technology. Ex. JPA instead of Hibernate.
As long as a sample app used only one service interface, that idea works. I'm just trying to think ahead a little. Note that a hierarchical directory structure isn't really important to the build process ... dependencies are declared by identifiers, not by relative location, no matter how they are organized.
The latter is what I'm planning to do with the MailReader entity classes ... > a jar project named "mailreader-jpa" in the sandbox (created locally on my > system, but not checked in yet). I'm thinking that we start out in the sandbox for everything related to this "petstore". Long term I don't see the advantage of having the domain objects in the sandbox but the apps in shale-apps.
We might want a separate grouping (parallel to shale-apps) for them. But the key thing is that they *don't* themselves depend on Shale, so they shouldn't IMHO just be intermixed with Shale artifacts, or Shale-dependent sample apps.
If "choose your view technology" means choosing between JSP/Clay/Facelets > but always using JSF components, this would be a matter of tweaking config > files and swapping out some of the resources. But I worry that the > machinery to make this happen would be complex enough and fragile enough to > hide the simplicity we're trying to show off. Yeah you're right. Its probably better to just document the slight variation. > My thinking is we want examples that have "one each" of the technology > choices that someone would have to make, and perhaps have part of the docs > talk about "if we had chosen xyz instead, we would have done this instead of > that." > > By the way, there is a very nice full featured demo of Clay already > (shale-clay-usecases). Ok so nobody will mind if I use facelets? We get a lot of questions about facelets on this list and the myfaces list.
Go for it! We have zero facelets based apps at the moment :-).
Craig Sean
Craig
