--- Please Note: This is a conv. I had with Craig and I cannot access bugzilla ATM, so I'm forwarding this to the full list with attachments. --- This email has my first email fo Craig, his reply and at last my new reply to both Craig and List.
/**** First Email ****/
Dear Craig:
I've been hacking shale a bit, mainly beacuse some needs our
organization
has regarding the default implementation of Dialog under base packages.
As a background, we have been taking a look and using shale in some
small
applications, but we've been thinking about hacking shale. To make you
understand our intentions, here is a small briefing:
What we really want is to have *ALL* our navigation (except ajax) go
throught dialogs. To achieve this, we have implemented a "default"
outcome
(transition) in all dialogs except the root one. That way, when you're
navigating through any dialog, at any time, you can ask the root dialog
(the menu) to start another one. The root dialog, which can be
considered
as the application menu, has all "Use Cases" as subdialogs. The default
target is (we're still thinking about it) always an exit (end) point for
all of the
sub-dialogs, so when you ask something that the dialog cannot
understand, it's
transfered to his parent dialog.
Using this aproach, we can start almost every dialog (except the root
one) in
any part/dialog of our application.
We have been thinking about implementing our navigation handler, but
you
(your team) has done a great effort with Shale, and almost all the
features we
want, except the one mentioned above are already implemented, so... why
reinventing the wheel?
My main question is, is there any way, without hacking deep on Shale
(our tests
only add 4 lines of code to the original Shale) to change the default
implementation
of Dialog?
So far, I've been added the following code to Shale navigation handler
private State transition(Status status, State state, String outcome)
method:
private static final String DEFAULT_TRANSITION = "default";
private State transition(Status status, State state, String outcome) {
<-- Line 526
if (transition == null) {
transition =
state.getDialog().findTransition(DEFAULT_TRANSITION);
if (transition == null) {
log.debug("No default transition found!"); //@todo: I18N
}
}
<--- line 527
}
Maybe you think this is useless but I've coded a small bean framework
that can
handle with this of aproach nicely, but I really need that "default"
transition on
dialogs to get it working with Shale.
I think it would be better to supply Shale with our own implementation
of Dialog,
just extending Shale's one and adding the above modifications to
findTransition method,
but AFAIK is not possible to do that, unless hacking inside at context
startup and
changeing the Dialogs found on it. I think it'd be really stupid because
adding just 2 lines
of code (plus debug code) will require much more effort than being able
to supply
Shale our own Dialog Impls.
I know Shale is still under development, and there are a lot of things
that are going to be
changed, but we find it stable enough to use it on several projects.
Can you please, give me some advise about how to perform this hack, or
just some
pointers about where to ask for more information?
/***** Craig Reply *****/
Juan,
Your ideas are certainly interesting ones. Unfortunately there is no current mechanism to specify your own custom implementation of DialogNavigationHandler ... that is a worthwhile enhancement request all by itself. As to the basic idea of your change, I personally get a little nervous about "magic" behaviors (such as going to a particular place when an unknown outcome is specified), but I can certainly see how it works for your use case.The best place to discuss Shale is on the Struts user mailing list (for user-related questions) and on the Struts developer list (for questions about changes to the code, like this one). You can find subscription information at [1] if you are not already subscribed. To file enhancemnent requests or bug reports in our issue tracking system at [2].Could you do me a favor and file an enhancement request for the "allow the developer to provide their own custom DialogNavigationHandler implementation"? I'm currently travelling, and am likely to forget about it along the way :-).Thank you very much in advance, and please forgive me if this is not the right way of contact Shale dev-team. PD: Excuse me about my English, since it's not my natural language. You do not need to apologize ... your English is very understandable.
/** My Final Reply to the list **/ Hi Craig (and devlist users),I'm writting to you but I'm sending this to the dev-mail list too because I'm uncertain if the attachments can reach the list, so please, rest of the dev-people, if this email hasn't attachments, it's not my fault
Fist of all, thank you for your response. ATM, I'm unable to submit it to bugzilla, we have a lot of restrictions here, and most of them include submitting postdata to most of the websites arround the world. It's difficult to get a site opened (at least apache.org is) but I cannot send postdata to it, so... I cannot login nor create bugzilla accounts. I've moved home too and I don't have DSL / modem at my new home yet.
The main problem I've found while trying to implement my Custom dialog handler has been the internal dialogs exposed by StateImpl, since they're not the same dialogs as the ones that exists in the context.
Mainly, users / devs will implement their dialog handler after shale's one get's up (at least that was what I did), in order to wrap those already configured dialogs, and then wrapping them to add a special behaviour:
- See attached chain-config.xml and ShaleConfigChainInit.javaThe dialogs are wrapped there with a custom class, but the problem is that StateImpl.getDialog() exposes the dialog of the state when the State was created/configured, and since dialogs had changed it's necesary to override findState and implement four states (viewstate, subdialogstate, endstate and actionstate).
- See attached DefaultBehaviourDialogWrapper.javaOne the other hand, one of the firsts ideas of a developer (like me) hacking shale, was to extend Shale's navigation handler, but most of the methods are private, so it's almost impossible to change the behaviour. After that, comes in mind wrap Shale's nav. handler, but it's likely a redofromscratch of Shale's one, just to change a few lines of code (see my original mail to Craig). So when a developer wraps navigation handler, He/She finds that trying to change the outcome wouldn't work in a simple/easy aproach: - See attached ShaleExtensionNavigationHandler.java (most methods are copied / pasted from DialogNavigationHandler.java) In that NavHandler, the outcome is changed, but what we want is to leave the outcome unchanged but redirect to a default-outcome instead.
Well, with all this samples / explanations, would somebody be kindly enough to fill a RFE for "allow the developer to provide their own custom DialogNavigationHandler implementation". I think it should be a way to have a navigation handler with protected methods so people can "hack" them if they need. It's not a problem of lazyness, I can use the original code, add my four lines and repackage it with my funcionality, but doing that means doing it everytime a new version of shale is out, and I think that's not a way to solve problems.
Thank all of you for your patient,PD: Please forgive those spanish coments in the code, I already know there's a mix of spanish / english coments...
Juan.
ShaleConfigChainInit.java
Description: java/
ShaleExtensionNavigationHandler.java
Description: java/
DefaultBehaviourDialogWrapper.java
Description: java/
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright 2004-2005 The Apache Software Foundation.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<catalogs>
<!-- Define preprocessing command chain for Shale to execute -->
<catalog name="shale">
<!-- shale necesita AMBOS init y DESTROY o de lo contrario cargara TANTO
INIT como DESTROY por defecto -->
<chain name="destroy">
<!-- Clean up dialogs configuration -->
<command className="org.apache.shale.dialog.config.ConfigurationDestroy"/>
</chain>
<chain name="init">
<command className="org.apache.shale.dialog.config.ConfigurationInit"/>
<command className="com.fi2net.base.ShaleConfigChainInit"/>
</chain>
<chain name="preprocess">
<!-- Incluye el catalogo SHALE con nombre REMOTE -->
<!-- Si se consigue un MATCH, se transfiere el control y se da por
terminada la cadena. -->
<command className="org.apache.commons.chain.generic.LookupCommand"
catalogName="shale"
name="remote"
optional="true"/>
<!-- Evita el acceso a los recursos .jsp y .jspf -->
<!-- Permite el acceso a los recuros .xml, .faces, .html, .gif,
/index.jsp, .jpg -->
<command className="org.apache.shale.application.ContextRelativePathFilter"
includes="\S*\.xml,\S*\.faces,\S*\.html,\S*\.gif,\S*\.jpg,/index\.jsp"
excludes="\S*\.jsp,\S*\.jspf"/>
</chain>
</catalog>
<!-- ========== Comandos de proceso remoto ============================== -->
<!-- (Los que salen del LifeCycle de Faces y Shale) -->
</catalogs>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
