Re: [OT] Interesting JSF info
My personal plan will be to do two things as soon as JavaServer Faces goes final. * Migrate my existing Struts based apps to using JavaServer Faces component tags, instead of Struts HTML tags, to take advantage of their additional functionality. Fortunately, this can be done with basically zero changes to the form beans and actions. Once JSF is released, will Tiles be considered a phased out technology similar to how JSTL and Struts-EL replaced the Struts Tag Libraries? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tiles-EL ???
Anyone know of a non-scriplet way to do what this jsp snippet is doing?
c:set var=editPage value=${config.editPage}/
% String editPage = (String) pageContext.getAttribute(editPage); %
tiles:insert page=%=editPage%/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Struts-EL, DynaActionForm, and HashMaps
Given this xml snippet from struts-config:
form-bean name=myForm type=org.apache.struts.action.DynaActionForm
form-property name=myMap type=java.util.HashMap/
/form-bean
and this JSTL snippet: (it prints out the firstName of a user bean
stored in the HashMap under the key mapEntry1)
c:out value=${myForm.map.myMap.mapEntry1.firstName}/
What do I put under the property attribute below to cause the
framework to update the firstName attribute of the bean stored under
mapEntry1 with the contents of the textbox when the page gets submitted?
html-el:form action=/map
html-el:text property=what goes here??/
/html-el:form
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 12 month contract - Toronto - immediate start
I'm kinda partial to the 2-5 years required experience with Oracle 9i. They are looking for a version of Winston Churchill who gained access to the Oracle 9i binaries back in April of '98. A time traveling Winston Churchill... One thing offends me the most is Excellent communication skills, both oral and written (10/10 essential) Looks like they are looking for Winston Churchill. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Advanced Tiles
After going thru Cedric's doc (http://www.lifl.fr/~dumoulin/tiles/tilesAdvancedFeatures.pdf) on Advanced Tiles Features I came up with something that's a slight derivative of the example on page 15, right under where it says, Example of a controller inserted as an URL:. That example shows how to associate a controller with a tile definition. The point in doing that (as far as my wee little brain can tell) is to try and make each tile as autonomous as possible. Right before each tile loads, an action gets invoked by the framework. This gives you a chance to execute business logic and prepare the request for the tile that's about to load. My issue is that I need a set of related actions to execute in an order that I can control before any of the tiles start to render. An example is a split screen where there is a tree of users displayed on the left, and a single user displayed on the right. This screen has /tree.do which preps the request for the tree, and /user.do which handles all the user updates. For the tree to display correctly I need /user.do to execute first (even though the tile it's associated with renders second), so that /tree.do has the updated information when it gets invoked. Here are the relevant snippets I came up with to get this behavior: At the top of layout.jsp: tiles:insert definition=user.controllers/ tiles.xml: definition name=user.controllers path=/WEB-INF/jsp/common/controller.jsp putList name=controllers add value=/admin/user.do/ add value=/admin/tree.do/ /putList /definition controller.jsp: tiles:importAttribute/ logic:iterate id=controller name=controllers type=java.lang.String tiles:insert page=%=controller% flush=false/ /logic:iterate This combination lets me execute an arbitrary set of actions in whatever order I want by simply editing tiles.xml. Is this a clever thing to be doing? A phenomenally bad idea? Is there (as there usually is) a simpler/different way to get this behavior? Any and all thoughts/comments/suggestions are welcome! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT]Credit card processing
I use the java API Verisign provides: http://www.verisign.com/products/payflow/pro/PayFlowPro.pdf Their API is functional tho not exactly elegant. I ended up putting a payment services layer in between our application code and the Verisign API calls mostly so I wouldn't be tied to Verisign any more than necessary, but also because some of their method/class names are really funky. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Contract Work: Going Rate?
On a side note related to contracting/consulting, do ya'll generally attempt to get the numbers on the table when you deal with 3rd party recruiting companies? Are you usually aware of what the recruiting company is charging the firm you are working for? Do you feel (like I do) that you have a right to know? I've been on 5 contracts over the past 3+ years: Pay Rate / Bill Rate / Duration $55 hr / $77 hr / 13 months $155 hr / $220 hr / 6 weeks $83 hr / $100 hr / 13 months $55 hr / $90 hr / 9 months $155 hr / $165 hr / 1 week Only once did a recruiting company initially refuse to divulge to me what the client was going to be charged. That project ended up embroiled in some nasty infighting with the project manager fighting with the HR rep who was fighting with the recruiting firm that was doing everything it could to hide the ridiculous difference between pay rate/bill rate. Nothing exposes the darker side of human nature better than a bare knuckled brawl over large chunks of cash. ;) After that experience one thing I do (if at all possible) is get the recruiter face to face, chat them up some, ask very pointedly what they are planning on charging the client for me, then sit back and watch the show. Very rarely do they just come right out and say a number, but if they break into a cold sweat and act like they are hiding the secret location of Sadaam's private bunker, be forewarned, composing elegant Java code is most likely one of the easier challenges you have in front of you... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Digester Best Practice
Ahhh. Ok. So something inside InputSource retains a reference to the base uri which keeps the parser happy. Makes perfect sense. We use xml includes a lot for our internal config files so knowing about this is a big time saver. Using the second form, with an InputSource, lets Struts say the absolute URL of the containing document is x, so that relative URLs can be resolved correctly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] struts/hibernate in Oracle mag
Why does no one use Jakarta's own OJB for persistence? Tons of people do! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Digester Best Practice
Any reasons for one of these approaches being better/worse than the other? URL url = Thread.currentThread().getContextClassLoader().getResource(/WEB-INF/test.xml); InputStream input = url.openStream(); Digester digester = new Digester(); digester.parse(input); URL url = Thread.currentThread().getContextClassLoader().getResource(/WEB-INF/test.xml); InputSource is = new InputSource(url.toExternalForm()); is.setByteStream(input); InputSream input = url.openStream(); Digester digester = new Digester(); digester.parse(is); ActionServlet does it the second way (InputSource), Tiles code does it the first way (InputStream). I ran into a problem getting Digester to parse xml documents that use includes with the InputStream method: !DOCTYPE xxx PUBLIC -//xx//xx 1.0//EN http://localhost/my-dtd.dtd; [ !ENTITY users SYSTEM users.xml ] my-xml users; /my-xml It throws org.xml.sax.SAXParseException: Relative URI users.xml; can not be resolved without a base URI. Switching to the InputSource method let Digester do it's thing, but I'm unclear on why. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Digester Subtlety
Any reasons for one of these approaches being better/worse than the other? URL url = Thread.currentThread().getContextClassLoader().getResource(/WEB-INF/test.xml); InputStream input = url.openStream(); Digester digester = new Digester(); digester.parse(input); URL url = Thread.currentThread().getContextClassLoader().getResource(/WEB-INF/test.xml); InputSource is = new InputSource(url.toExternalForm()); is.setByteStream(input); InputSream input = url.openStream(); Digester digester = new Digester(); digester.parse(is); ActionServlet does it the second way (InputSource), Tiles code does it the first way (InputStream). I ran into a problem getting Digester to parse xml documents that use includes with the InputStream method: !DOCTYPE xyz PUBLIC -//xyz//xyz 1.0//EN http://localhost/xyz.dtd; [ !ENTITY users SYSTEM users.xml ] abc users; /abc It throws org.xml.sax.SAXParseException: Relative URI users.xml; can not be resolved without a base URI. Switching to the InputSource method let Digester do it's thing, but I'm unclear on why. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Digester Subtlety
Apologies for the duplicate msg. I got a somewhat cryptic reply that the orginal had bounced, presumably because it had xxx in the xml doctype area. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles and WebSphere
David Graham wrote: It's actually a small bug in the Tiles insert tag. In tiles-defs.xml I define these definitions: definition name=tiles.leftnav path=/layout/leftnav.jsp !-- this is the optional secure part of the navigation -- put name=secureLeftNav value=/ /definition !-- defines the secure leftnav piece to insert into main leftnav -- definition name=tiles.secureLeftNav extends=tiles.leftnav put name=secureLeftNav value=/layout/secureLeftNav.jsp/ /definition The first definition defines an optional attribute called secureLeftNav. The second definition extends the first and defines a jsp for that attribute. When hitting a page that uses definition 1 I receive a response already committed error because the tag tries to do an include on a null page (note that this only happens in WAS 5, not Tomcat 4.1.18). I'll commit a fix tonight where the tag will simply return if the page variable is null. I'm getting something similar that I think is the same thing, is your fix in the latest nightly? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design Idea: FormBasedDispatchAction
Wendy Smoak wrote:
Jeff wrote
Just store the mappings between submit buttons and methods in the
ApplicationResources.properties file along with everything else, and
then extend LDA in such a way that it looks in there to figure out which
method to invoke.
LDA already does that, you don't need to extend it. Just add the
'parameter' attribute to the action tag, make your action extend
LookupDispatchAction, and implement the getKeyMethodMap method.
What I thought you meant was add lines to AppResources.properties that
supplied the mappings LDA needs in getKeyMethodMap():
#Normal button stuff
button.delete=Delete
button.ok=Ok
#New mappings used only by LDA
myAction.handleUpdate=button.ok
myAction.handleDelete=button.delete
Then implement getKeyMethodMap() something like this:
protected Map getKeyMethodMap() {
Properties props = logic to load ApplicationResources.properties
Enumeration keys = props.keys();
Map map = new HashMap();
while(keys.hasMoreElements()) {
String key = (String)keys.nextElement();
if (key.startsWith(myAction.)) {
String method = key.substring(key.indexOf(myAction.) + 1);
String button = props.get(key);
map.put(button,method);
}
}
return map;
}
That way if the need arises to handle a cancel button, all that is
required to route the request to the proper method is two lines in the
properties file:
button.cancel=Cancel
myAction.handleCancel=button.cancel
If that's not what you meant, you get credit for inspiring a new
thought, but I'm taking credit for the thought itself :-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [THURSDAY] struts questions
Bueno Carlos M wrote: just had to stick the zip file inside my tom cat. I do have a cat, but she's female. Will that make a difference, or does struts only run on male cats? Does it matter if they are neutered? Does each client need to have a male cat or just the server? Ever since they came out with the Struts RC1, Craig has been recommending all pets in the house be spayed or neutered prior to running the example app. Not really sure why. Might be a good question for the struts-dev mailing list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Design Idea: FormBasedDispatchAction
I'm thinking of extending the DispatchAction supplied in the Struts
download for my app by overriding the execute() method as described
below, any negative/positive feedback on this one?
public abstract class FormBasedDispatchAction extends DispatchAction {
/**
* This class assumes that a DynaActionForm is associated with this
action and that the form has a property called method.
* Whatever that property is set to is the method this class uses
reflection to invoke.
*/
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response) throws Exception {
//cast the generic form to a DynaActionForm
DynaActionForm dynaForm = (DynaActionForm) form;
//pull out what method is set to
String method = (String) dynaForm.get(method);
//execute that method
return dispatchMethod(mapping, form, request, response, method);
}
}
My own thoughts are:
Positive:
Very simple :-)
Don't have to make a source code mod to your Action each time the text
on a submit button in the JSP is added/changed like you do with
DispatchAction
Negative:
It's a slight abuse of the Struts form object. Form's now would carry
one bit of data that helps out the controller logic in addition to
carrying user entered data.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design Idea: FormBasedDispatchAction
snip Maybe you are referring to the LookupDispatchAction Yes, LookupDispatchAction. Sorry. The way I originally extended LDA, each Action contained a hard coded mapping of submit button values- method names. (obviously a bad thing :-) Wendi's idea, if I'm getting it right, sounds pretty good. Just store the mappings between submit buttons and methods in the ApplicationResources.properties file along with everything else, and then extend LDA in such a way that it looks in there to figure out which method to invoke. That seems cleaner since: 1) Anytime we are adding/changing a button we'll be editing that file anyways 2) The button that was clicked gets automatically submitted as part of the request (no need for an extra hidden HTML form element in all the JSP's) 3) It removes the method attribute from all of our Struts forms 4) If for some reason we ever need to execute a bit of locale specific logic in the Action, it would be as simple as adding a line to that locale's property file. Oh shoot. I just remembered the other thing that was tripping me up with LDA. We had a few screens where more than one button shared the same text but had entirely different meanings. (Two OK or Delete buttons in different areas) Since LDA does a reverse lookup based on the text I was back to either client side JS or if-then-else logic in the method of the action. I think since screens without duplicate buttons outnumber screens with them by something like 10-1 we'll go the ApplicationResources.properties route. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] How to tell when a project you are on is in trouble
I think (hope?) that it's a joke Andrew. Although the subject line makes me think that it might be real and therefore very, very worrying.
I'm sad to say, it's very real. He found it debugging a problem that
was coming out in the stacktrace as a NullPointerException. Since
NullPointerException supports chaining it took 4-5 seconds to find the
line of code causing the NullPointerException and 4-5 hours trying to
unravel what the real cause of the problem was. Turned out to be an IO
problem (related to permissions I think) where the code was dutifully
catching IOException but just ignoring it and instead re-throwing
NullObjectException.
The architect of the project a friend of mine is on just unleashed
this beauty into the source tree, thought ya'll might get a
kick out of it:
/**
* NullObjectException
*
* Copyright © 2001,2002 ## Corp. All rights reserved.
* This exception is used if the object must not be null and it is
*
* @author #
*/
public class NullObjectException extends Exception {
// Doesn't have to do anything
}
Note how neatly this disables nested exception handling!!!
Pretty nice eh??
Jeff Caddel
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[OT] How to tell when a project you are on is in trouble
The architect of the project a friend of mine is on just unleashed
this beauty into the source tree, thought ya'll might get a kick out of it:
/**
* NullObjectException
*
* Copyright © 2001,2002 ## Corp. All rights reserved.
* This exception is used if the object must not be null and it is
*
* @author #
*/
public class NullObjectException extends Exception {
// Doesn't have to do anything
}
Note how neatly this disables nested exception handling!!! Pretty nice eh??
Jeff Caddel
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Struts Console as a Web Application
Does anybody know of a web application with functionality similar to that of the Struts Console 2.1 James Holmes wrote? Basically a web interface for managing the various struts xml config files similar to the way the admin webapp manages the Tomcat server.xml file. TIA!!! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
