Struts Dreamweaver extension

[Anthony Chater]

We are testing the Compuware Struts tag Dreamweaver extension in
MacromediaUltradev as this appears to be the most complete Struts visual
tooling around.  However we are not having 100% in achieving what we need.

Our situation is as follows :
We receive HTML files from a design bureau and convert them to JSP files
which we then load into a site in Ultradev. We then "doctor" the jsps with
the Struts tags.  What we want to do is roundtripping with the design bureau
:
By this we mean that when minor changes occur  we want to be able to zip up
the whole site and send it back to the design bureau. 
They should be able to work with the (now JSP and Struts tag-enabled) pages,
make their changes, zip up the site and send it back to us so that we can
continue working.(We would ensure that the design bureau had the
necessary tag library extensions to load into their Ultradev work
environments)

There are 2 questions which arise here :

1. Is our concept of roundtripping outlined above feasible? 

2. Most important :  assuming we set up our site with a live datasource
which the actions can call,  will our Struts-enables pages then be rendered
in Ultradev the way they actually appear or will we still get the "flower
symbols" in place of  Struts tags and the layout discrepancies which now
occur.

Anthony Chater

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Generate Javascript popup from Action

[Anthony Chater]

I have a page which calls an Action  in the standard way. However in some
situations, ie as a result of logic executed in my Action class,  I need to
generate a popup window on top of the page before proceeding.  Is it
possible to do this from within my action?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Form beans in tag library

[Anthony Chater]

Can I  get a handle on my form beans in my own tag library?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

logic:notPresent tag doesn't work

[Anthony Chater]

In the Struts-example application the logic:notPresent tag is used in
index.jsp to check whether the Application resources file was loaded.
However I've tested this and it doesn't work. You still get a bunch of
missing key error messages .
Any suggestions


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Customised Error handling

[Anthony Chater]

The HTMLErrors tag handles validation errors well and of course I can load
other text messages into an  ActionError and present them via an HTML:errors
tag. 
But I need to have at least one other category of  error message. 
 Is there a built-in mechanism for doing this or do I have to write my own
tag?



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: problem with i18n

[Anthony Chater]

Try ApplicationResources_de_CH.properties

Format is : BasicBundle + _  + languagecode + _ + countryCode

> -Original Message-
> From: rgi [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, October 31, 2001 3:30 PM
> To:   [EMAIL PROTECTED]
> Subject:  problem with i18n
> 
> Hello struts-user,
> 
> 
> 
> 
> I have a problem with i18n.
> I have setup in the web.xml file this
> ch.netcetera.webapp.struts.ApplicationResources
> and I added in the ch/netcetera/webapp/struts directory two files:
> ApplicationResources.properties
> ApplicationResources_de-ch.properties
> 
> With jsp I look witch language I use and this is OK. But struts us
> ever the ApplicationResources.properties.
> 
> <%
>   String lang = request.getHeader("Accept-Language");
>   out.println(lang);
>   boolean headerSuccess = false;
>   if (lang != null){
> if (lang.length() >= 2){
>   session.putValue(org.apache.struts.action.Action.LOCALE_KEY, new
> java.util.Locale(lang.substring(0, 2), "") );
>   headerSuccess = true;
> }
>   }
>   if (headerSuccess){
> %><%
>   }
>   else{
> out.println("Header 'Accept-Language' either not found or has no
> recognisable value.");
>   }
> %>
> 
> This jsp code print me always the string key for index.title in the
> ApplicationResources.properties.
> 
> Have someone a answer to that problem?
> 
> 
> -- 
> Best regards,
>  rgi  mailto:[EMAIL PROTECTED]
> 
> 
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Feedback on Struts Pros and Cons

[Anthony Chater]

Hi,

I've just finished building  a prototype using Struts and talking to EJB
session beans at the back end and can give you a brief sum up of my own
practical experiences 
without answering you point for point :
The chief adavantages are :
simplified  error handling (some) / easy internationalisation / automatic
form handling - think of validation and parameter retrieval / ready-made tag
libraries for code-free JSPs / localisation of all action handling

Incidentally some of the disadvantages you list are trivial : almost every
servlet based framework I've worked with requires at least one class to be
programmed per action.
A Struts tip : think in terms of Actions not pages;   so actions can be
reused by many pages
And.. Data entry validation can be  toggled per JSP (per form actually; you
simply don't implement the validate method if you don't want it!)

Disadvantages are :
- only for JSP / servlets
- a relatively steep learning curve (but thereafter vastly improved
productivity)
- you're bound to the Struts tag libs if you use them (which you should). If
you ditch Struts you can start layouting again -:)
-  (your point )internationalization is limited to static strings


Cheers
Anthony


PS  
I only subscribed to this newsgroup today and the messages are all streaming
into my mailbox.  I's there a !@#$%%%$#@  newsgroup where on can anser this
sort of thing using a normal newsgroup reader?



> -Original Message-
> From: David Bueche [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, October 31, 2001 2:23 PM
> To:   [EMAIL PROTECTED]
> Subject:  Feedback on Struts Pros and Cons
> 
> All,
> 
> I work with a company that is new to Java and we are evaluating tools for
> a standard J2EE architecture.  One of the Model 2 approaches we are
> looking at is Struts.
> 
> After spending some time evaluating Struts, I have assembled the attached
> list of pros and cons, but would like to get some impartial third party
> feedback.  If anyone sees anything I missed, I would appreciate your
> insights.
> 
> Thanks!
> 
> -David
> 
> --
> 
> Struts Advantages:
> 
> 1. Provides a controller ActionServlet that dispatches requests to the
> appropriate business actions (Action subclasses) provided by the
> application developer.  All dispatching is defined in an XML file
> (struts-config.xml).
> 
> 2. Supports internationalization of messages and prompts.
> 
> 3. Provides message collections that can be easily displayed in a
> subsequent JSP/Servlet.
> 
> 4. Allows the input (data entry) JSP/Servlet to be specified for each
> Action subclass, so control can be returned to that JSP/Servlet in the
> case of an error.
> 
> 5. Provides custom tags to delegate many of the JSPs' HTML commands and
> Servlets' "println" statements to tag libraries.
> 
> 6. Automates population of the JSP domain object (ActionForm subclass)
> with input data.
> 
> 7. Allows data entry validation (ActionForm subclass) and business logic
> (Action subclass) to be decoupled from the presentation JSPs/Servlets.
> 
> 8. Data validation can be turned on or off in web.xml.
> 
> 
> Struts Disadvantages:
> 
> 1. Instead of direct dispatching by controller Servlet(s), dispatching is
> defined in an XML file, adding a layer of indirection overhead to the
> architecture.
> 
> 2. Requires behavior typically factored for commonality in controller
> Servlet methods to be duplicated in every Action subclass (some common
> behavior could possibly be delegated to additional classes or components
> and accessed by each Action subclass).
> 
> 3. Struts internationalization is limited to static strings and does not
> include internationalization of data returned by a business component.
> 
> 4. Struts internationalization requires an ApplicationResources.properties
> file, which conflicts with the current Enterprise Java Application
> Standard of definely properties directly in the web.xml file.
> 
> 5. Presentation of message collections is predefined in tag libraries
> (although these could be modified for more specialized presentation).
> 
> 6. Requires understanding of custom tags and tag libraries, as well as
> their deployment.  While this may not be a problem for more advanced
> developers, this will add another layer of complexity for less experienced
> development and support teams and requiring more intensive EAS
> involvement.
> 
> 7. Delegating much of the presentation layer to custom tags can make the
> final HTML/presentation less clear than HTML placed directly in the
> JSPs/Servlets.
> 
> 8. Data entry validation is toggled on/off on a global basis only (not on
> a per JSP/Servlet basis).
> 
> 9. Requires recompilation and redeployment when data entry validation or
> business component invocation changes.   This is unnecessary if data entry
> validation and business component invocation is performed in a JSP.
> 
> 10. Requires at least one additional class per deployed page: an Action
> subclass to invoke the correspondi