I use Zero Conf and codebehind a lot, and I think they're both incredibly
useful. especially in this newer world of convention over configuration,
etc... When I have a package hierarchy all set up, i don't feel the need to
muck with struts.xml, because I can get directly down to coding.

There are cases where you have to go back to struts.xml ( like wildcarding,
and being able to customize and manage interceptor refs ) , and that needs
some looking into.

In my opinion, ZeroConf and Codebehind need to be together, and available as
a plugin, because they work so well together. This is sort of where the
smart-urls plugin ( a great piece of work, too ) comes in. Maybe effort
should be placed into that to plump that up and 'robusticate it' ( as my
co-worker likes to say )

In my perception of the near-future world, some additions to zc/cb or
smart-urls . some flex-json style ability for the json plugin, a bit of
guice and warp, and you've got a very easy development cycle.

-a






Zarar Siddiqi wrote:
>
> I think the Zero Configuration idea is a nice idea but the
> implementation is far from sufficient and will probably get better
> over time (hopefully). The problem mainly is with the limit of
> annotations. There are things that can be represented in struts.xml
> that have no chance of being represented via action annotations. For
> example, package interceptors, global results, multiple execute
> methods in the same action etc. etc.
>
> Even if you do manage to represent what you want in annotations as you
> have, it quickly turns ugly and you end up wondering why you're even
> bothering mucking up your nice and clean action bean with stuff like
> contentType, text/xml and paths to FTLs. struts.xml is a very
> powerful little method of making your actions behave any which way you
> want and I'd even prefer it over annotations unless you're doing
> something very, very basic.
>
> The other issue I think is the lack of the "convention over
> configuration" philosophy being used. For example, if you have have
> an action called myAction, there's no reason why by default it
> shouldn't look like for something like myAction_success.jsp and
> myAction_input.jsp instead of having this specified by the user. This
> idea can be extended to interceptors, global results etc. I'm just
> blurting out what's on the top of my head but there are many more ways
> to make Zero Config better.
>
> Thanks,
> Zarar
>
>
> On 10/2/07, Sami Dalouche <skoobi@(protected):
>> Hi,
>>
>> On http://struts.apache.org/2.x/docs/release-notes-209.html, I can
>> read : "Please help us test these brave new features. Feedback
>> appreciated".
>>
>> So, here is some feedback about Zero configuration :
>>
>> - the feature is pretty cool, though not much documented. For instance,
>> it was not obvious to me what the "params" parameter meant in the
>> @Result annotation, and I had to dig into the source code to understand
>> that odd indexes where the keys and even ones where the values...
>>
>> So, a freemarker view that would return XML would be described as
>> @Results( { @Result(name = "success", value =
>> "/WEB-INF/views/blabla.ftl", type = FreemarkerResult.class, params = {
>>           "contentType", "text/xml" }) })
>>
>> - I have been looking for a way to specify the default package, but it
>> looks like I have to manually copy / paste the following line for my
>> actions to use the "default" package settings :
>> @ParentPackage("default")
>>
>> - And last, I am experiencing some weird problems... Basically, 9 times
>> out of 10, everything is fine, but sometimes, for no particular reason,
>> the @ParentPackage("default") line in my actions seem to have no effect
>> and the zero-conf Actions use the struts provided default stack, not the
>> one that I defined in my default package.. (either the web application
>> boots correctly and works for its whole uptime, or it doesn't work at
>> all. When it doesn't work, the only way to get it working it by
>> rebooting the web application).
>>
>> I have absolutely no idea about the reasons that could cause that...
>> Have you heard of anything similar before ?
>>
>> Regards,
>> Sami Dalouche
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@(protected)
>> For additional commands, e-mail: user-help@(protected)
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@(protected)
> For additional commands, e-mail: user-help@(protected)
>
>
>

--
Sent from the Struts - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)