ide an unified way
> of handling these type of urls. Thoughts?
>
> musachy
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additi
k Floyd
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>
>
--
View this message in context:
http://old.nabble.com/parameters-in-url-tp25602877p29708616.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
:
>>
>> committed to trunk. To use it set:
>>
>>
>>
>>
>>
>> to use it with convention, convention needs to be built from trunk.
>>
>> musachy
>>
>>
>
> --
> View this message in context:
> http://www.nabble.
>
> musachy
>
>
--
View this message in context:
http://www.nabble.com/parameters-in-url-tp25602877p25683653.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-uns
committed to trunk. To use it set:
to use it with convention, convention needs to be built from trunk.
musachy
On Thu, Sep 24, 2009 at 2:19 PM, Musachy Barroso wrote:
> I find that using parameters in urls is confusing in struts, and there
> are just too many (and not compatible) ways of
very confusing and hard to understand. I would like to do this:
>>>
>>> class MyAction {
>>> String param1, param2, param3;
>>>
>>> �...@action("/{param1}/{param2}/MyAction/{param3}")
>>> public void execute() {}
>>> }
>>>
>>> and the framework should figure out the rest
my opinion
the /url/url/param/param is REST right, we need use convention
and the package is the old model
how can it run in the your dev envionment?
F
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional
handling these type of urls. Thoughts?
>>
>> musachy
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> --
hi there
i believe we cannot mix the old package xml with rest right
--
Frans Thamura
Meruvian.
Experiential Tempation of Java and Enterprise OpenSource
Meruvian bukan hanya membuat anak SMK menjadi bisa tapi SAKTI, malah
saktinya SAKTI Mandraguna.
Mobile: +62 855 7888 699i
Blog & Profile: h
"Careful with that axe Eugene"
The only change in xwork would be in
AbstractMatcher:replaceParameters, because that method gets the params
defined in the action mapping ({1}), and
replaces it with the value extracted from the URL. My change is to
also include additional params, so the field names
Be careful overriding the pattern matcher. I use it in xwork to
include files in the xml configuration provider.
-W
On 9/24/09, Musachy Barroso wrote:
> meh, this one didn't put up much of a fight :). With these set
> ("regex" alternative implementation of patternMatcher):
>
>
>
>
>
> I c
meh, this one didn't put up much of a fight :). With these set
("regex" alternative implementation of patternMatcher):
I can do this:
/tags/ui/example.jsp
calling "/WorldDomination/test/LexLuthor" will set "bio" to
"WorldDomination" and "name" to "LexLutho
I find that using parameters in urls is confusing in struts, and there
are just too many (and not compatible) ways of doing it, for example,
if you want to have parameters in front of the action name, like
/something/param1/param2/ActionName
you would have to use the "namedVariable" action mapper
13 matches
Mail list logo
