Ted Husted wrote:
On Nov 1, 2007 5:02 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
I think there are two changes I'm going to make:
1. Remove smarturls.action.packages and replace this with
smarturls.action.package.identifiers, which is the list of identifiers
that package names must contain. This would default to
"action,actions,struts,struts2". This would require two annotations and
two properties to turn specific packages on and off.
What's the motivation for this change? What's wrong with a list of one
or more base packages?
This is verbose and honestly annoying. We are planning on having a large
number of components (~30), so including each component's action
packages by hand in each applications struts.properties file is
something I am currently avoiding using component.xml and any change
will have to retain that concept. This is why I prefer the identifiers
method. It provides even more convention and less configuration.
I think in practice, people either setup a specific package for Struts
Actions, or mix them in with other classes and use an "Action" suffix
to distinguish them from other similar classes. (For example a Person
entity class and a PersonAction class.)
I would say that entities in the same package as actions is something I
wouldn't ever do, but is something others might go for. I find that my
best practices dictate a clean separation of domain, services, and
actions. My packages are like:
com.example.action
com.example.domain
com.example.service
Vertigo will have crud scaffolding that defaults to this layout as well.
If people are using some other strange organizational scheme, I think
it's all right to encourage people to use a more common scheme
instead. I know a lot of people who refactored their database schemas
to use Hibernate (and ended up with a better schema in the end).
Agreed.
2. Remove the component.xml file handling for components and rely on
the changes in #1 to find actions and result locations for components.
+1
+1 as well. Now if we can just get JPA to allow EntityManagerFactory to
load multiple persistence.xml files with the same persistence-unit and
JNDI datasource value I'd be set. Unfortunately I still need to put my
component's entity classes into the component.xml file because of JPA.
This would make it simpler to start working and create java-packages
that contain actions. Plus, it would support all the component
infrastructure that I need in a completely standard fashion.
Could you explain what "component infrastructure" is needed?
I've built a component infrastructure that allows me to create a
component that contains services, entities, actions and views
(FreeMarker). I can drop that component into the classpath (using
Savant) of any application and I immediately have new admin CRUD and all
of the entities available with no configuration changes. This is very
powerful in the consulting world because it means I can add features to
applications without any coding.
So, whenever I'm talking about components I'm referring mostly to a JAR
file in WEB-INF/lib that contains Struts2 action classes and FreeMarker
results that are accessible via HTTP or AJAX.
Before I was using component.xml to manage all of the component stuff
like action packages and result locations within the JAR files. However,
if I change the action package resolution to use identifiers and package
level annotations for result locations than I don't need the
component.xml file at all. If we stick with the other solution and drop
component.xml I'll have to start adding in the component's action
packages to my applications by hand or via some tool.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
