----- Original Message -----
From: "Dmitri Colebatch" <[EMAIL PROTECTED]>
Dmitri - thanks for your quick reply...
> I'd argue that whilst what you say is correct, the way it is is still in
> line with the idea of xdoclet. Basically coders like coding, not working
in
> config files. The way I see it (and note, others probably have diff
> opinions), I would want to start a system with xdoclet, and if I was
> releasing it in binary, then the config files would be created with some
> defaults - an admin could then change them.
No argument there.
Perhaps the generation needs to be a bit smarter so that rather than the
file being completely rewritten that the local forwards can be retained from
any previous struts-config?
I'm just not sure how you'd go about having an admin change them and then
later overlay the hand-modified one and the XDoclet generated one. Any
advice on how that could be done?
> to do it all in one file - the source file. this does arguably break mvc,
> but its at development time, and does so in a way that doesn't prevent you
> simply switching to a pure mvc come release time.
I'm involved in a very extensive Struts project right now and the nice thing
about struts-config is that if single-purpose simple actions are available
you can do a lot of interesting things by chaining actions together or by
initially developing with a simple pass-through action (I call it
SuccessAction, it simply forwards to "success") and when more functionality
needs to be injected the action mapping is updated to point to a custom
action, and perhaps even the forward is updated to chain to another action
rather than going directly to a JSP.
> you typically would have lots of merge files... not ideal.
Agreed - I'm just not sure how to handle the need to separate controller
from view.
> I have just moved house, and will soon be back on deck - and we're about
to
> get a heap of struts work at work, so I will no doubt be putting some time
> in there.
Excellent... I look forward to seeing how it goes and how the struts-config
XDoclet stuff evolves.
Erik
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
