If the keys and values of your Map are basic classes like String and
Integer, then encoding it as an even-sized array of service parameters
(i.e., sp=key1&sp=value1&sp=key2 ...) is more efficienct than encoding it as
sp=...serializedMap...
The latter is much larger (hundreds of characters, minumum) and more
expensive when encoding and decoding (it requires slow Java object
serilaization and a GZIP filter).
I have a feeling we're in agreement on this.
However, having a couple of static methods in Tapestry to convert between
Object[] and Map would shift this issue over to the Direct's listener
method. And, with the magic of OGNL:
<binding name="parameters"
expression="@net.sf.tapestry.Tapestry@convertMapToArray(parametersMap)"/>
Would invoke getParametersMap() and pass the result to the hypotheical
convertMapToArray static method. Then the listener
public void directListener(IRequestCycle cycle)
{
Map map = Tapestry.convertArrayToMap(cycle.getServiceParameters());
...
}
About initialization ...
I do think this is a good idea; I've just been overbooked and haven't moved
it into the code. My only minor quibble is with the name, I tend to avoid
abbreviations whenever possible, so I would name initPage() something more
like initializePageState().
I don't see a problem with an inherit-informal-parameters attribute on the
<component> element. I'm trying to stabilize 2.2 for rc, so I'm hesitant to
put it in now.
----- Original Message -----
From: Mind Bridge
To: [EMAIL PROTECTED]
Sent: Saturday, September 07, 2002 9:57 AM
Subject: Re: [Tapestry-developer] [ tapestry-Feature Requests-603132 ] Add a
service similar to ExternalService
Hi Howard,
Your comments on the External service are right on the money. Here are some
additional comments of mine:
- We have actually named the service 'ParameterPage' here, since in terms of
functionality, it is like a Page service, but allows parameters. I am
certainly not picky about the name, though :)
- I think the interface for setting/getting parameters would ideally use the
same principles as that used by Direct. I see no reason why they should be
different -- any argument in favour of using a Map in External would be
valid with equal force for using a Map in Direct. In addition, using similar
approaches would provide consistency, which I personally think is important
at this level.
I want to make one more point related to that: Neither an array of Obects
nor a Map are inherently limiting, as long as the serialization mechanism
you introduced in 2.2 is available. One can put an array in the map, and a
map in the array. I think the real issue is what would be more practical in
the general case. Personally, I think Map is a better choice, since it is
easier to maintain and you don't have to "define" an order of placing
parameters (something that often causes problems in the long run), but given
the fact that the two are interchangable, I am personally am not
particularly picky about that either.
A few comments on my other feature request:
A new page object is often developed using the following structure:
class CTestPage extends BasePage {
private String m_strPrimaryField;
public CTestPage() {
m_strPrimaryField = "primary";
}
public void detach() {
super.detach();
m_strPrimaryField = "primary";
}
}
Suppose you now want to add a new field at a later stage, say
m_strSecondaryField. Since the detach() method may be buried further down
in the page (new methods have been inserted before it, for example), it is
entirely possible that the developer adds an initialization of this field in
the constructor, but forgets to add one in the detach() method. In order to
prevent this from happening (and it did occur relatively often, especially
with newbies), we standardized on the following approach:
class CTestPage extends BasePage {
private String m_strPrimaryField;
public CTestPage() {
init();
}
public void detach() {
super.detach();
init();
}
private void init() {
m_strPrimaryField = "primary";
}
}
In this way all field initializations occur in a single location, and are
identical independently of whether the page is newly created or it has been
detached.
Obviously, despite the init(), you still have the freedom to do one-time
initializations in the constructor (e.g. fields immutable during the entire
lifetime of the object) or cleanup actions in the detach() method (e.g.
closing a transaction that may have been opened during the request cycle).
I think this approach can save a lot of tears, hence my suggestion to add a
protected initPage() method in AbstractPage and have it called by the
constructor and the default detach() implementation, as well as recommend
its use in the documentation. Most importantly, such a change is very simple
in addition to being completely backward compatible and not breaking any
existing code.
Finally, one last question: do you think it makes sense to provide a
mechanism for inheriting informal parameters, similar to inherit-binding?
Often when you have one component wrap another, you want to pass its
informal parameters to the inner component. Since there is no standard
mechanism for passing informal parameters (I think), we've had to develop a
very simple component named 'InheritInformalAny", that is similar to Any,
but inherits the informal parameters of the parent. Suprisingly, it has seen
quite a bit of use on numerous places. Recently we've had the need for other
components to inherit informal bindings from their parent, but fortunately
we have circumvented that by wrapping the components in span or div tags
managed by InheritInformalAny. I am not sure that is a universal solution,
however.
In short: there is a real case for having something like that, but
personally I cannot think of a good solution other than modifying the
component spec DTD in some way, which may be a bit too late for now. In any
case, what do you think?
-mb
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
