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
