Daniel Fagerstrom pisze:
Grzegorz Kossakowski skrev:
Daniel Fagerstrom pisze:
What about omitting "/" part while asking for list of servlet bean ids?
It seems even more logical to me because the syntax will be:
servlet:[<bean id or connection name>:]/<rest of the path>
[] - means that it's optional part
Doesn't seem that logical to me. For all other schemes directory URIs
ends with a "/". It will confuse people to have another convention in
this particular case. Furthermore it would not comply with
http://tools.ietf.org/html/rfc3986.
You are right, it was a weak attempt.
Thinking further on it. The URIs of current servlet protocol are only
valid within the scope of a specific servlet service, outside it it
lacks meaning. The URIs of the proposed servlets: protocol has a unique
meaning in the scope of the whole webapp. URIs with webapp scope is
needed both for the "global list" use case as well as for the "global
id" use case that you and Alexander have discussed.
I think we make the servlet: protocol unnecessarily complicated if we
try to overload it with webapp global interpretations as well.
But we need to do that way. If Source returns globally unique URI it means that is must handle it. That's why we must implement block id
handling in the servlet: source.
And as I asked before, how does the URI parser given e.g.
"servlet:foo/bar" know is "foo" is a servlet service local id or a
Spring bean id?
It should try both options or we could could introduce some syntax that makes
it easy to distinguish these two cases.
Of course I'm very happy with all your coding. But if you would like to
write RTs, don't let your ideas about your English abilities limit you.
The fastest way to improve your ability to write good RTs, is to
actually write RTs ;) As long as the ideas interest people, they will
try to understand and give you feedback.
I will remember what you said but for now finishing already started things
should have highest priority.
Servlets already are available for anyone coding Java, as they are
ordinary Spring beans. So we have not any protection of them anyway.
For most blocks it is much preferable to use the current servlet service
wiring style as it clearly declares dependencies, and make it possible
for a user to compose and replace servlet services as they want.
But there are important use cases for run time discovery of servlet
services as well. The current use case with a samples main page is one
example. I mean you want it to work both for a normal build and an
-Dallblocks build.
I see, thanks for clarification.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
