@Chris - Those are definitely good points. I think that our first priorities
for the applications we build for the Health System are maintainability &
readability. We don't have the performance needs of a major public internet
site. Our sites are pretty zippy. ;-) Usually we have more large dataset
related issues than throughput. I suppose in a major system you could
subdivide your routes into different includes for different modules. I
think if I was having performance issues, I would look a few other places
first before I look before reducing the number of variables.
@MG - maven scripts for Ruby on Rails? Am I missing something? JRuby
perhaps? but its a struts forum, so we can move on... ;-)
In the example there is one namespace with all the RESTful actions
associated with a Customer (index, show, new, create, edit, update,
destroy). When creating the links, the ids change plurality based on
conventions I have seen:
//GET /customers/index = customers_path
//GET /customers/show?id=1 = customer_path
//GET /customers/new = customers_new_path
//POST /customers/create = customers_create_path
//GET /customers/edit?id=1 = customer_edit_path
//POST /customers/update = customer_update_path
//POST /customers/destroy?id=1 = customer_destroy_path
You can place your <s:url/> inline for the anchor's href attribute. I think
my intent was to abstract the view page from the action's implementation
which allows me to update the namespace or action without a big search and
replace. With refactor tools these types of updates are pretty trivial.
IMO, the url "reads" better with the JSTL variable reference.
On precedence, the short answer is I don't. I set includeParams default
globally to false and just deal with query strings, "the old way". Its
just my preference, but I like to see the querystring params on each link
rather than just the unique additions on top of the existing GET params. I
think my general habits keep the querystrings fairly light, but in a
situation where you need a big complex querystring that you are chaining you
can always put in an "exception" and do it however you want for that case.
I have not built anything that needed a performance boost from offloading
static resource loading from another server. I have read that this is a
common technique used to gain some perceived performance gain on the browser
side.
On the maven archetype, I wish I wasn't so lazy. I still need to create an
archetype for the template we are using for our apps. We stripped Appfuse
and retooled it with some better unit test classes and integrated it with
SSO (Crowd) and we just need to get it all wrapped up. I really need to
create a template folder for Musachy's StrutsOn so I can use Groovy to
generate all the Dao/Managers/Controllers/Views for basic CRUD based on
models. Maybe one night I can put down Left4Dead and get some work done
instead....
mgainty wrote:
>
>
> MG>comments?
> ______________________________________________
> Disclaimer and confidentiality note
> Everything in this e-mail and any attachments relates to the official
> business of Sender. This transmission is of a confidential nature and
> Sender does not endorse distribution to any party other than intended
> recipient. Sender does not necessarily endorse content contained within
> this transmission.
>
>>
>>
>> Sorry it took me a while. Damn flu season...
> MG>we're ALL waiting for nationalised health insurance!
>>
>> Anyways, its not really complicated but I have found it to be useful. It
>> was inspired from some RoR projects I worked on and is a poor mans
>> routing
>> table.
> MG>i compiled a RoR one time ..havent been able to get the module-ror
> compiled since
> MG>i think the project was abandoned as I have'nt been able to get ahold
> of maven scripts
> MG>to create the module properly..
>
>>
>> You create a JSP that you will include at the top of all your JSP views.
>> In
>> this JSP you add url tags like:
>>
>> <s:url id="customers_path"
>> namespace = "/customers"
>> action = "index"/>
>>
>> <s:url id="customer_path"
>> namespace = "/customers"
>> action = "show"/>
> MG> i assuming <s:url id="customer_paths" instead of duplicating
> custome_path?
> MG>change url2 namespace from customers to customer?
>
>> <s:url id = "customers_new_path" ...etc, etc
>>
>> The naming convention and use of singular and plurals for certain names I
>> lifted from Rails conventions.
>>
>> Then in your view JSPs where the above is included, you use a JSTL
>> expresssion like:
>>
>> <a href="${customers_path}">Customers Index</a>
> MG>anchor href uses prebuilt urls is already implemented in showcase.jsp
> (v2.1.6)
> MG><li> <s:url action= includeParams="none" />">Action Chaining </li>
>
>>
>> Since you are globally including this you don't parameterize urls like
>> "customer_path" in the routes page, but just write out the query string
>> like
>> you would on a normal link.
>>
>> <a href="${customer_path}?id=${customer.id}">Customers Index</a>
> MG>then in the the case where
> <-- Example 2 -->
> <s:url action="editGadget">
> <s:param name="id" value="%{#parameters.search['id'}"
> />
>
> <s:url action="edit" includeParams="get">
> <s:param name="id" value="%{'22'}" />
> </s:url>
>
> the value 22 will be assigned over any customer.id as the
> includeParams="get" takes precedence
>
> http://struts.apache.org/2.x/docs/url.html
> How would you handle the scenario of assignment precedence for
> includeParams?
> MG>
>> (You could use <s:property/> tags but for the links I find the less
>> verbose
>> JSTL expressions to be prettier.)
>>
>> The other type of urls you can put in there are things like home, images,
>> styles, scripts, etc. So you can serve these static resources from
>> wherever.
>>
>> <s:url id = "home"
>> value = "/"/>
>>
>> <s:url id = "images"
>> value = "/images"/>
>>
>> Then in the JSP its
>>
>> ${images}/add.png
>> <link rel="stylesheet" href="${styles}/home.css"/>
>> <script src="${scripts}/jquery/jquery.js"></script>
>>
>> So you could have something called dev-routes.jsp where the static
>> resources
>> are served relatively through your J2EE container
> MG>J2EE container serving faster than Apache?
>
>>and in prod-routes you
>> could change it to serve from a separate Apache server
> MG>Apache http-server serves static resources faster than any J2EE
> compliant container
>
>> to make things
>> fasterish:
>>
>> <s:url id="images"
>> value="http://mystatic1.site.com/images/"/>
>>
>> I have been using this pattern on the last 3 or 4 projects and it has
>> really
>> stuck without much changes. I suppose we could add some maven profiles
>> and
>> maven variables in there to switch values based on the selected maven
>> build
>> profile.
> MG>are you voluntering to create a maven archetype for this?
> MG>anyone else?
> MG>thanks for the info..this has been helpful
> MG>
>>
>> mgainty wrote:
>> >
>> >
>> > dave answered about namespace
>> >
>> > curious about 'routes pattern'
>> >
>> > thanks,
>> > Martin
>> > ______________________________________________
>> > Disclaimer and confidentiality note
>> > Everything in this e-mail and any attachments relates to the official
>> > business of Sender. This transmission is of a confidential nature and
>> > Sender does not endorse distribution to any party other than intended
>> > recipient. Sender does not necessarily endorse content contained within
>> > this transmission.
>> >
>> >
>> >
>> >
>> >> Date: Thu, 12 Mar 2009 20:23:57 -0700
>> >> From: dustin_pea...@yahoo.com
>> >> To: user@struts.apache.org
>> >> Subject: RE: this is driving me nucking futs!
>> >>
>> >>
>> >> Sorry Martin, did Dave answer your question? Were you just wondering
>> >> about
>> >> the namespace parameter on the url tag or about the routes pattern in
>> >> general?
>> >>
>> >>
>> >> mgainty wrote:
>> >> >
>> >> >
>> >> > can you explain this routes a bit more..what is this another
>> attribute
>> >> or
>> >> > a template?
>> >> > i can see see action, params but namespace?
>> >> >
>> >> > if you look at the code the base class changes from
>> >> > public class AnchorTag extends AbstractClosingTag
>> >> > TO
>> >> > public class AnchorTag extends ContextBean
>> >> > basing AnchorTag on a bean allows you to tack on infinitely more
>> >> > attributes
>> >> > ...
>> >> > Martin
>> >> > ______________________________________________
>> >> > Disclaimer and confidentiality note
>> >> > Everything in this e-mail and any attachments relates to the
>> official
>> >> > business of Sender. This transmission is of a confidential nature
>> and
>> >> > Sender does not endorse distribution to any party other than
>> intended
>> >> > recipient. Sender does not necessarily endorse content contained
>> within
>> >> > this transmission.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >> Date: Thu, 12 Mar 2009 09:24:54 -0700
>> >> >> From: dustin_pea...@yahoo.com
>> >> >> To: user@struts.apache.org
>> >> >> Subject: Re: this is driving me nucking futs!
>> >> >>
>> >> >>
>> >> >> Adding the action, namespace and params url constructing pieces to
>> s:a
>> >> >> would
>> >> >> be cool, as long as we don't nerf the s:url function. I rather
>> like
>> >> the
>> >> >> pattern of using a central "routes" page as an include where urls
>> are
>> >> >> created and their ids referenced in links via JSTL in the main
>> pages.
>> >> >>
>> >> >> -D
>> >> >>
>> >> >> newton.dave wrote:
>> >> >> >
>> >> >> > mitch gorman wrote:
>> >> >> >> I AM AN INSTRUMENT OF CHANGE!!!
>> >> >> >
>> >> >> > Hmm, when people say that about me they say I'm a tool.
>> >> >> >
>> >> >> > I'm not *entirely* sure they're being complimentary ;)
>> >> >> >
>> >> >> > Dave
>> >> >> >
>> >> >> >
>> >> >> >
>> >> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>> >> >> > For additional commands, e-mail: user-h...@struts.apache.org
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/this-is-driving-me-nucking-futs%21-tp22463203p22479288.html
>> >> >> Sent from the Struts - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>> >> >> For additional commands, e-mail: user-h...@struts.apache.org
>> >> >>
>> >> >
>> >> > _________________________________________________________________
>> >> > Windows Live™ Groups: Create an online spot for your favorite groups
>> to
>> >> > meet.
>> >> > http://windowslive.com/online/groups?ocid=TXT_TAGLM_WL_groups_032009
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/this-is-driving-me-nucking-futs%21-tp22463203p22489517.html
>> >> Sent from the Struts - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>> >> For additional commands, e-mail: user-h...@struts.apache.org
>> >>
>> >
>> > _________________________________________________________________
>> > Windows Live™ Contacts: Organize your contact list.
>> >
>> http://windowslive.com/connect/post/marcusatmicrosoft.spaces.live.com-Blog-cns!503D1D86EBB2B53C!2285.entry?ocid=TXT_TAGLM_WL_UGC_Contacts_032009
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/this-is-driving-me-nucking-futs%21-tp22463203p22509369.html
>> Sent from the Struts - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>> For additional commands, e-mail: user-h...@struts.apache.org
>>
>
> _________________________________________________________________
> Windows Live™: Life without walls.
> http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_032009
>
--
View this message in context:
http://www.nabble.com/this-is-driving-me-nucking-futs%21-tp22463203p22519872.html
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
