mixing service and non-service classes in a package

[Andrus Adamchik <an...@objectstyle.org>]

Hi folks,

While I am generally happy with the clean default package structure of  
a tapestry app, I am running into a snag with the coding style we've  
been using with T4 and got quite used to. Each service package looks  
something like this:

<root>/services/s1/IService  (service interface)
<root>/services/s1/Service   (default implementation)
<root>/services/s1/Helper1   (some non-public helper class)
<root>/services/s1/Helper2   (some other non-public helper class)

As you there are often extra non-public classes that help to make the  
main implementation class more readable. This of course doesn't play  
well with tapestry as these extra classes are in the same package as  
"Service", but they are not declared in the module, so Tapestry (5.2)  
throws.

I can either move Helper1 and Helper2 out of the "services/s1" package  
and make them public, or split a superclass out of Service and move it  
to another package together with Helper1 and Helper2. In either case  
clean organization of the project is broken.

So I was wondering if there is a way to tell Tapestry to just ignore  
the helper classes when enhancing the service class? So how others are  
dealing with the issue of organizing complex non-public service code?

Thanks,
Andrus

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org