RE: ErrorsTag (was /contrib)

[Howard Moore]

Since you are making changes in this area how about also extending the
ActionError class so that it can hold an exception if one has been thrown? 

What I want to do when a serious problem occurs is to divert to an error
page, display a friendly error message and write details of the problem as
an html comment. I can do this at the moment by storing the Exception in the
request but it would be more convenient if it was part of the ActionError,
particularly if there is more than one.


> -Original Message-
> From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
> Sent: 12 July 2001 06:33
> To: [EMAIL PROTECTED]
> Subject: Re: ErrorsTag (was /contrib)
> 
> 
> I checked in the changes I've made.  There is an
> html:messages tag that iterates through the errors and
> is basically the same as the tag I had in the
> validator class except for the changes that were
> discussed.  I've made an ActionMessages class and
> ActionMessage class.  ActionErrors now extends
> ActionMessages and ActionError extends ActionMessage,
> but should work the exact same (basically the code
> from the errors classes is just in the parent).  My
> thinking was that an error is basically a more a
> specific type of message.  
> 
> I haven't added the messagesExist tag yet because I'm
> not sure where it belongs.  All the logic tags are
> very generic.  Maybe it belongs in a taglib/validator
> package.  If you read this Craig, maybe you could
> comment.
> 
> David
> 
> --- Ted Husted <[EMAIL PROTECTED]> wrote:
> > David Winterfeldt wrote:
> > > This would work, but would it be confusing for a
> > > general message tag to default to errors? 
> > Originally
> > > when I did this I was thinking that for general
> > > messages there could be ActionMessage,
> > ActionMessages,
> > > Action.MESSAGE_KEY, etc.  And there would still be
> > the
> > > equivalent ones for errors, but they would
> > subclass
> > > the general message ones and use Action.ERROR_KEY.
> > 
> > I'm just thinking that the "default" messages would
> > be errors, but you
> > could also use the same tags for general messages by
> > supplying another
> > id, for example the Action.MESSAGE_KEY. 
> > 
> > So "errors" are just the default messages, but you
> > can use the same tags
> > for managing any other message queues desired, just
> > by supplying a
> > message id (and/or alternate headers and footers). 
> > 
> > Alternatively, the tag could take a switch like
> > "messages=true" to use
> > the MESSAGE_KEY key. The default could be
> > "messages=false", which would
> > use the standard ERROR_key.
> > 
> > To be consistent, we would use messagesExist with
> > the same properties,
> > and let it default to the ERROR_KEY. 
> > 
> > This leaves the html:errors as it is, and makes the
> > message tags a new
> > series with more functionality, that use the old
> > ERROR_KEY by default,
> > but can be used with other queues as well.
> > 
> > -Ted.
> 
> 
> __
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
> 

RE: extract .jsp name in extended HtmlTag

[Young, Wayne]

That works too. I ended up going with:

 HttpServletRequest req = (HttpServletRequest)
this.pageContext.getRequest();
 StringBuffer resource = new StringBuffer(req.getServletPath());

Would one be preferred over the other?

Just FYI, we're 2.5 weeks from code cutoff with our 1st release that is
"Powered by Struts".  But we have an early 1st code cutoff... we're still
2-3 months from GA. We're up to 46 action classes at this point... it should
double/triple by the end of the release. I can't imagine how many we'll have
at the end of next release. 

All is well and Struts evangelists are starting to crawl out from
everywhere.

Thanks to all the Struts developers for a great product.

Wayne
[EMAIL PROTECTED]



-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 11, 2001 10:00 PM
To: Struts-Dev@Jakarta. Apache. Org (E-mail)
Subject: Re: extract .jsp name in extended HtmlTag




On Wed, 11 Jul 2001, Young, Wayne wrote:

> I need to modify HtmlTag to output the .jsp name of the page that
contained
> the  tag in a hidden field or comment. This is for debugging
and
> also to link into our help system.
> 
> Any ideas on how to do this from within doStartTag()?
> 

You could do something like:

HttpServletRequest request = (HttpServletRequest)
  pageContext.getRequest();
String requestURI = request.getRequestURI();

sb.append("");

just before the ResponseUtils.write() call.

Alternatively, you might consider just using the  tag in your
 section.  This will render a  element that includes the
absolute path of the current page -- and, as an extra added bonus it will
make relative references to images and stylesheets work correctly, even
when you forward to this page from a Action.

> Thanks.
> 
> Wayne
> [EMAIL PROTECTED]
> 

Craig

Re: New name for Components / Extended Templates?

[Cedric Dumoulin]

  "Tiles" sound nice too, and is in the same way as "Struts", but its French
translation has a bad connotation.
  Among the proposed names, we have :

   * viewparts
   * viewpieces
   * tiles (bad connotation in french)
   * portlets   (already in used by other projects)
   * pieces
   * blocks
   * snippets
   * layouts(maybe too restrictive)

  First ones are my preferred, and I will certainly use "viewparts".
  Cedric

"Craig R. McClanahan" wrote:

> On Wed, 11 Jul 2001, Immanuel, Gidado-Yisa wrote:
>
> > How about VIPs :)
> >   a. Very Important Pieces
> >   b. View In Pieces (hmmm...kind of has a negative connotation)
> >
> > or how about
> >
> >   Tiles
> >
> > (just finished redoing a kitchen floor)
> >
>
> I like it (tiles) :-)
>
> Craig
>
> >
> > > -Original Message-
> > > From: Cedric Dumoulin [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, July 10, 2001 11:53 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: New name for Components / Extended Templates?
> > >
> > >
> > >
> > >   As Components can be used to build "views" of the MVC
> > > framework, it could
> > > be interesting to have the term "view" in the new name.
> > >   I have thought about "viewlet", but this is already used ;-).
> > >   Maybe "viewparts" or "viewpieces" ? This sound nice and can
> > > reflect the
> > > fact that framework is for building views by assembling
> > > parts/pieces of
> > > view.
> > >Comments ?
> > >
> > > Cedric
> > >
> > > Cedric Dumoulin wrote:
> > >
> > > >   Components / Extended Templates framework will be added to Struts
> > > > shortly.
> > > >
> > > >   It is now the last chance to rename this framework if necessary.
> > > >
> > > > Primary idea of the framework was to allow building of JSP pages by
> > > > assembling reusable pieces of code, called blocks or
> > > components. One of
> > > > the aims is to provide a library of easily reusable components (like
> > > > standard layouts, but also reusable menus, common login
> > > form, shopping
> > > > card, ...).
> > > >   Templating mechanism is naturally done with the framework, but
> > > > framework can also provide a starting point for reusable components.
> > > >
> > > >   So what's wrong with name "components" ? Component is a
> > > broad term in
> > > > English, and it may be confusing when people talk about Struts
> > > > components in general. So maybe we should change actual Components
> > > > framework name.
> > > >
> > > >   Why not renaming "Components" to "templates" ? Framework
> > > allow more
> > > > than templating, If we call it "templates", I am afraid that people
> > > > identify framework
> > > > with only the template mechanism, missing the ability to
> > > define reusable
> > > > piece of pages. Also, this would break the actual templates
> > > > implementation.
> > > >
> > > >   After discussions with Ted Husted,  we propose following
> > > alternatives
> > > > :
> > > >
> > > >  Framework name package name
> > > >  JSP pieces / Extended Templates
> > > >(as a play on Java Faces ;-) jsp-pieces or pieces
> > > >  JSP Blocks jsp-blocks or blocks
> > > >  Dynamic Templates  templates
> > > >
> > > >   My preference goes to (JSP pieces / Extended Templates),
> > > jsp-pieces.
> > > >
> > > >   I need your opinion on this renaming :
> > > >
> > > >* Do we really need to do it ? (A lot of peoples already use
> > > >  components. This could lead to troubles)
> > > >* Which name do you prefer / propose ?
> > > >
> > > > Cedric
> > >
> >

RE: New name for Components / Extended Templates?

[Rey Francois]

Cedric,

Ok thanks, I understand. The reason I asked is because I quite like the word
"tiles" because of the image of putting tiles together in order to beautify
a flat surface.

I think anyway that not many people will use (or think of) the French
translation, but will use the English word instead, don't you think so? 

Fr.

-Original Message-
From: Cedric Dumoulin [mailto:[EMAIL PROTECTED]]
Sent: 12 July 2001 15:23
To: Rey Francois
Subject: Re: New name for Components / Extended Templates?



  Hi Rey,

  In my dictionary there is at least two translations : 'carreau' and
'tuiles'.
The second one have several meaning in French : its first signification is
the
same as in English : a tile on a roof. But in slang, "avoir une tuile" or
"il y
a une tuile" means to be unlucky, have a problem.
  It looks like calling a program "bug" ;-)

Cedric

Rey Francois wrote:

> Cedric,
>
> I'm not sure I see what's the bad connotation in French for 'tiles'.
What's
> the translation for you in French and what do you mean?
>
> Fr.
>
> -Original Message-
> From: Cedric Dumoulin [mailto:[EMAIL PROTECTED]]
> Sent: 12 July 2001 14:13
> To: [EMAIL PROTECTED]
> Subject: Re: New name for Components / Extended Templates?
>
>   "Tiles" sound nice too, and is in the same way as "Struts", but its
French
> translation has a bad connotation.
>   Among the proposed names, we have :
>
>* viewparts
>* viewpieces
>* tiles (bad connotation in french)
>* portlets   (already in used by other projects)
>* pieces
>* blocks
>* snippets
>* layouts(maybe too restrictive)
>
>   First ones are my preferred, and I will certainly use "viewparts".
>   Cedric
>


The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.

http://www.capco.com
***

RE: New name for Components / Extended Templates?

[Young, Wayne]

How about "Units"?

Wayne
[EMAIL PROTECTED]

-Original Message-
From: Cedric Dumoulin [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 12, 2001 7:13 AM
To: [EMAIL PROTECTED]
Subject: Re: New name for Components / Extended Templates?



  "Tiles" sound nice too, and is in the same way as "Struts", but its French
translation has a bad connotation.
  Among the proposed names, we have :

   * viewparts
   * viewpieces
   * tiles (bad connotation in french)
   * portlets   (already in used by other projects)
   * pieces
   * blocks
   * snippets
   * layouts(maybe too restrictive)

  First ones are my preferred, and I will certainly use "viewparts".
  Cedric

"Craig R. McClanahan" wrote:

> On Wed, 11 Jul 2001, Immanuel, Gidado-Yisa wrote:
>
> > How about VIPs :)
> >   a. Very Important Pieces
> >   b. View In Pieces (hmmm...kind of has a negative connotation)
> >
> > or how about
> >
> >   Tiles
> >
> > (just finished redoing a kitchen floor)
> >
>
> I like it (tiles) :-)
>
> Craig
>
> >
> > > -Original Message-
> > > From: Cedric Dumoulin [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, July 10, 2001 11:53 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: New name for Components / Extended Templates?
> > >
> > >
> > >
> > >   As Components can be used to build "views" of the MVC
> > > framework, it could
> > > be interesting to have the term "view" in the new name.
> > >   I have thought about "viewlet", but this is already used ;-).
> > >   Maybe "viewparts" or "viewpieces" ? This sound nice and can
> > > reflect the
> > > fact that framework is for building views by assembling
> > > parts/pieces of
> > > view.
> > >Comments ?
> > >
> > > Cedric
> > >
> > > Cedric Dumoulin wrote:
> > >
> > > >   Components / Extended Templates framework will be added to Struts
> > > > shortly.
> > > >
> > > >   It is now the last chance to rename this framework if necessary.
> > > >
> > > > Primary idea of the framework was to allow building of JSP pages by
> > > > assembling reusable pieces of code, called blocks or
> > > components. One of
> > > > the aims is to provide a library of easily reusable components (like
> > > > standard layouts, but also reusable menus, common login
> > > form, shopping
> > > > card, ...).
> > > >   Templating mechanism is naturally done with the framework, but
> > > > framework can also provide a starting point for reusable components.
> > > >
> > > >   So what's wrong with name "components" ? Component is a
> > > broad term in
> > > > English, and it may be confusing when people talk about Struts
> > > > components in general. So maybe we should change actual Components
> > > > framework name.
> > > >
> > > >   Why not renaming "Components" to "templates" ? Framework
> > > allow more
> > > > than templating, If we call it "templates", I am afraid that people
> > > > identify framework
> > > > with only the template mechanism, missing the ability to
> > > define reusable
> > > > piece of pages. Also, this would break the actual templates
> > > > implementation.
> > > >
> > > >   After discussions with Ted Husted,  we propose following
> > > alternatives
> > > > :
> > > >
> > > >  Framework name package name
> > > >  JSP pieces / Extended Templates
> > > >(as a play on Java Faces ;-) jsp-pieces or pieces
> > > >  JSP Blocks jsp-blocks or blocks
> > > >  Dynamic Templates  templates
> > > >
> > > >   My preference goes to (JSP pieces / Extended Templates),
> > > jsp-pieces.
> > > >
> > > >   I need your opinion on this renaming :
> > > >
> > > >* Do we really need to do it ? (A lot of peoples already use
> > > >  components. This could lead to troubles)
> > > >* Which name do you prefer / propose ?
> > > >
> > > > Cedric
> > >
> >

RE: New name for Components / Extended Templates?

[Immanuel, Gidado-Yisa]

I just want to be able to say :)

  I've put the struts in my web app,
  now I'm ready to tile it.

Or when people ask me, "what do you do?"

  Oh, I tile web sites...

- Gidado

> -Original Message-
> From: Rey Francois [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 12, 2001 9:19 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: New name for Components / Extended Templates?
> 
> 
> Cedric,
> 
> Ok thanks, I understand. The reason I asked is because I 
> quite like the word
> "tiles" because of the image of putting tiles together in 
> order to beautify
> a flat surface.
> 
> I think anyway that not many people will use (or think of) the French
> translation, but will use the English word instead, don't you 
> think so? 
> 
> Fr.
> 
> -Original Message-
> From: Cedric Dumoulin [mailto:[EMAIL PROTECTED]]
> Sent: 12 July 2001 15:23
> To: Rey Francois
> Subject: Re: New name for Components / Extended Templates?
> 
> 
> 
>   Hi Rey,
> 
>   In my dictionary there is at least two translations : 'carreau' and
> 'tuiles'.
> The second one have several meaning in French : its first 
> signification is
> the
> same as in English : a tile on a roof. But in slang, "avoir 
> une tuile" or
> "il y
> a une tuile" means to be unlucky, have a problem.
>   It looks like calling a program "bug" ;-)
> 
> Cedric
> 
> Rey Francois wrote:
> 
> > Cedric,
> >
> > I'm not sure I see what's the bad connotation in French for 'tiles'.
> What's
> > the translation for you in French and what do you mean?
> >
> > Fr.
> >
> > -Original Message-
> > From: Cedric Dumoulin [mailto:[EMAIL PROTECTED]]
> > Sent: 12 July 2001 14:13
> > To: [EMAIL PROTECTED]
> > Subject: Re: New name for Components / Extended Templates?
> >
> >   "Tiles" sound nice too, and is in the same way as 
> "Struts", but its
> French
> > translation has a bad connotation.
> >   Among the proposed names, we have :
> >
> >* viewparts
> >* viewpieces
> >* tiles (bad connotation in french)
> >* portlets   (already in used by other projects)
> >* pieces
> >* blocks
> >* snippets
> >* layouts(maybe too restrictive)
> >
> >   First ones are my preferred, and I will certainly use "viewparts".
> >   Cedric
> >
> 
> **
> **
> The information in this email is confidential and is intended solely
> for the addressee(s).
> Access to this email by anyone else is unauthorised. If you are not
> an intended recipient, you must not read, use or disseminate the
> information contained in the email.
> Any views expressed in this message are those of the individual
> sender, except where the sender specifically states them to be
> the views of Capco.
> 
> http://www.capco.com
> **
> *
> 

generation of taglib doc

[Brennan.OShea]

Can someone tell me how the documentation for the Struts taglibs
(http://jakarta.apache.org/struts/struts-html.html) is currently
generated?  I first assumed that this doc was generated from the .tld
files via XSLT or some other method.  However, the tld doesn't contain
all of the necessary information, i.e."description", to generate those
pages.  I'm wanting to incorporate the changes I've made to the Struts
tags into the doc for my company, but don't want to spend a lot of time
writing/maintaining HTML.  I assume I could add my own tags to the .tld
files for "description" and whatever else I needed, then write some XSL
to display it -- but I would like to know how others are approaching
this issue.  Also, I remember hearing at Java One that this type of doc
generation will be better facilitated in JSP 1.2 and after looking at
the JSP 1.2 PFD2, it looks like several tags have been added to the .tld
files, one being "description".  I'd appreciate any suggestions.

Thanks!

Brennan O'Shea

Indexed tags to be committed...

[dhay]

Hi everyone,

Please find attached latest version of tags.  As mentioned below, the link tag
will create an extra parameter in the link if "indexed=true" is specified.
Default is for this parameter to be named 'index', but this can be changed by
specifying "indexId=myParamName" to change it.

If everyone is in agreement, please could someone commit the attached code?  I
have made the changes against the 1.0 release version of tags (don't know if
anyone has made any other changes to these files since then?).

Cheers,

Dave

PS  What about changes to documentation?  Do I need to write something for
these?

(See attached file: struts indexed files.ZIP)




David Hay
07/11/2001 10:44 AM

To:   [EMAIL PROTECTED]
cc:

Subject:  Re: Re[2]: Indexed tags - proposal to add changes  (Document link:
  David Hay)

Hi Martin,

Good point.  But I would lean towards leaving the "indexed=true" to make it the
same as all the other tags, and make the "indexId=..." as optional ie default to
naming the parameter we add "index" which they can change using
"indexId=myParamName" if they want to.

If no-one has objections, I will go ahead and do this, and post the code to the
list.

Cheers,

Dave




"Martin Cooper" <[EMAIL PROTECTED]> on
07/11/2001 12:56:45 AM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject:  Re: Re[2]: Indexed tags - proposal to add changes



Thinking about this some more, if we have the 'indexId' attribute, do we
need the 'indexed' attribute as well? Wouldn't the specification of a value
for 'indexId' imply 'indexed="true"' anyway?

--
Martin Cooper


- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 10, 2001 1:07 PM
Subject: Re: Re[2]: Indexed tags - proposal to add changes


>
>
> Have changed the LinkTag to allow users to specify the indexId.
>
> After doing some more investigation, don't think your first suggestion,
Oleg,
> would ever come up.  If the user specifies the paramName, Id and property
in a
> link in a particular row in the table ie in your example:
>
> >  > paramId="whenSell" includeIndex="yes">
>
> I believe the user will expect to simply see the sell.when value for that
> iteration, which is what the current tag will do!  Thus the includeIndex
(or
> index=true), if this is their intention, is not necessary at all.
>
> So...suggest that the only usage required will be:
>
> 
>...
> paramProperty="value" indexed="true" indexId="recordNo">a
>...
> 
>
> which would produce (for the first iteration) the following link:
>
> a
>
> One question for you all - do we want to default the indexId to something
(eg
> "index=") or do I throw an exception if index="true" is specified without
> indexId?
>
> Should then be ready to submit code...
>
> Cheers,
>
> Dave
>
>
>
>
>
> "Martin Cooper" <[EMAIL PROTECTED]> on
> 07/10/2001 12:28:40 AM
>
> Please respond to [EMAIL PROTECTED]
>
> To:   [EMAIL PROTECTED]
> cc:(bcc: David Hay/Lex/Lexmark)
> Subject:  Re: Re[2]: Indexed tags - proposal to add changes
>
>
>
> +1 for 'indexed="true"'
>
> +1 for 'indexId'
>
> --
> Martin Cooper
>
>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Oleg V Alexeev" <[EMAIL PROTECTED]>
> Sent: Monday, July 09, 2001 9:35 AM
> Subject: Re: Re[2]: Indexed tags - proposal to add changes
>
>
> >
> >
> > Hi.  Does anyone have any comments on this?  Personally I would opt for
> leaving
> > includeIndex="yes" as indexed="true" to match other syntax.
> >
> > But, do we want to provide both types of indexed links?
> >
> > Cheers,
> >
> > Dave
> >
> >
> >
> >
> >
> > Oleg V Alexeev <[EMAIL PROTECTED]> on 07/07/2001
> 02:03:25 AM
> >
> > Please respond to [EMAIL PROTECTED];
> Please
> >   respond to Oleg V Alexeev <[EMAIL PROTECTED]>
> >
> > To:   [EMAIL PROTECTED]
> > cc:(bcc: David Hay/Lex/Lexmark)
> > Subject:  Re[2]: Indexed tags - proposal to add changes
> >
> >
> >
> > Hello dhay,
> >
> > Link tag must build name of some parameter on base of index value or
> > use it as separate parameter (I agree with you... 8) )
> >
> >  > paramId="whenSell" includeIndex="yes">
> >
> > with result as - http://.../news.do?whenSell=today[30]
> >
> > Or
> >
> >  > includeIndex="yes" indexId="myIndex">
> >
> > with result as - http://.../news.do?id=2&myIndex=30
> >
> > Friday, July 06, 2001, 10:10:33 PM, you wrote:
> >
> >
> >
> > dlc> Oleg,
> >
> > dlc> Hi.  Agree that the link tag is different, but think that it is due
> to its
> > dlc> nature!  Unlike the other tags, adding index as a query param seems
> to me
> > the
> > dlc> only reasonable way to provide access to the index in the link.
Not
> sure
> > how
> > dlc> else to do it (if you try and use name, obviously you change the
link
> into
> > an
> > dlc> anchor!).
> >
> > dlc> If you (or anyone else) has any suggestions to handle it in a
better
> way
> > would
> > dlc> like to hear them - maybe I missed something!
> >
> > dlc> C

Re: Indexed tags to be committed...

[Oleg V Alexeev]

Hello dhay,

+1 to add

Friday, July 13, 2001, 2:03:06 AM, you wrote:

dlc> Hi everyone,

dlc> Please find attached latest version of tags.  As mentioned below, the link tag
dlc> will create an extra parameter in the link if "indexed=true" is specified.
dlc> Default is for this parameter to be named 'index', but this can be changed by
dlc> specifying "indexId=myParamName" to change it.

dlc> If everyone is in agreement, please could someone commit the attached code?  I
dlc> have made the changes against the 1.0 release version of tags (don't know if
dlc> anyone has made any other changes to these files since then?).

dlc> Cheers,

dlc> Dave

dlc> PS  What about changes to documentation?  Do I need to write something for
dlc> these?

Add new attributes descriptions to every tag has been changed and
change whole tag description to describe new additions and logic.

dlc> (See attached file: struts indexed files.ZIP)

dlc> David Hay
dlc> 07/11/2001 10:44 AM

dlc> To:   [EMAIL PROTECTED]
dlc> cc:

dlc> Subject:  Re: Re[2]: Indexed tags - proposal to add changes  (Document link:
dlc>   David Hay)

dlc> Hi Martin,

dlc> Good point.  But I would lean towards leaving the "indexed=true" to make it the
dlc> same as all the other tags, and make the "indexId=..." as optional ie default to
dlc> naming the parameter we add "index" which they can change using
dlc> "indexId=myParamName" if they want to.

dlc> If no-one has objections, I will go ahead and do this, and post the code to the
dlc> list.

dlc> Cheers,

dlc> Dave




dlc> "Martin Cooper" <[EMAIL PROTECTED]> on
dlc> 07/11/2001 12:56:45 AM

dlc> Please respond to [EMAIL PROTECTED]

dlc> To:   [EMAIL PROTECTED]
dlc> cc:(bcc: David Hay/Lex/Lexmark)
dlc> Subject:  Re: Re[2]: Indexed tags - proposal to add changes



dlc> Thinking about this some more, if we have the 'indexId' attribute, do we
dlc> need the 'indexed' attribute as well? Wouldn't the specification of a value
dlc> for 'indexId' imply 'indexed="true"' anyway?

dlc> --
dlc> Martin Cooper


dlc> - Original Message -
dlc> From: <[EMAIL PROTECTED]>
dlc> To: <[EMAIL PROTECTED]>
dlc> Sent: Tuesday, July 10, 2001 1:07 PM
dlc> Subject: Re: Re[2]: Indexed tags - proposal to add changes


>>
>>
>> Have changed the LinkTag to allow users to specify the indexId.
>>
>> After doing some more investigation, don't think your first suggestion,
dlc> Oleg,
>> would ever come up.  If the user specifies the paramName, Id and property
dlc> in a
>> link in a particular row in the table ie in your example:
>>
>> > > > paramId="whenSell" includeIndex="yes">
>>
>> I believe the user will expect to simply see the sell.when value for that
>> iteration, which is what the current tag will do!  Thus the includeIndex
dlc> (or
>> index=true), if this is their intention, is not necessary at all.
>>
>> So...suggest that the only usage required will be:
>>
>>  property="parameterList">
>>...
>>> paramProperty="value" indexed="true" indexId="recordNo">a
>>...
>> 
>>
>> which would produce (for the first iteration) the following link:
>>
>> a
>>
>> One question for you all - do we want to default the indexId to something
dlc> (eg
>> "index=") or do I throw an exception if index="true" is specified without
>> indexId?
>>
>> Should then be ready to submit code...
>>
>> Cheers,
>>
>> Dave
>>
>>
>>
>>
>>
>> "Martin Cooper" <[EMAIL PROTECTED]> on
>> 07/10/2001 12:28:40 AM
>>
>> Please respond to [EMAIL PROTECTED]
>>
>> To:   [EMAIL PROTECTED]
>> cc:(bcc: David Hay/Lex/Lexmark)
>> Subject:  Re: Re[2]: Indexed tags - proposal to add changes
>>
>>
>>
>> +1 for 'indexed="true"'
>>
>> +1 for 'indexId'
>>
>> --
>> Martin Cooper
>>
>>
>> - Original Message -
>> From: <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>; "Oleg V Alexeev" <[EMAIL PROTECTED]>
>> Sent: Monday, July 09, 2001 9:35 AM
>> Subject: Re: Re[2]: Indexed tags - proposal to add changes
>>
>>
>> >
>> >
>> > Hi.  Does anyone have any comments on this?  Personally I would opt for
>> leaving
>> > includeIndex="yes" as indexed="true" to match other syntax.
>> >
>> > But, do we want to provide both types of indexed links?
>> >
>> > Cheers,
>> >
>> > Dave
>> >
>> >
>> >
>> >
>> >
>> > Oleg V Alexeev <[EMAIL PROTECTED]> on 07/07/2001
>> 02:03:25 AM
>> >
>> > Please respond to [EMAIL PROTECTED];
>> Please
>> >   respond to Oleg V Alexeev <[EMAIL PROTECTED]>
>> >
>> > To:   [EMAIL PROTECTED]
>> > cc:(bcc: David Hay/Lex/Lexmark)
>> > Subject:  Re[2]: Indexed tags - proposal to add changes
>> >
>> >
>> >
>> > Hello dhay,
>> >
>> > Link tag must build name of some parameter on base of index value or
>> > use it as separate parameter (I agree with you... 8) )
>> >
>> > > > paramId="whenSell" includeIndex="yes">
>> >
>> > with result as - http://.../news.do?whenSell=today[30]
>> >
>> > Or
>> >
>> > > > includeIndex="yes" indexId="myIndex">
>> >
>> > with result as - http://.../news.do?id=2&myIndex=30
>> >
>> > Friday, July 06, 2001, 10:10:33 PM, you wrote:
>

digester

[Rakesh]

Is there a better example availiable anywhere of 
the struts digester than the struts-config file ?
Any good working examples ?
 
 
 Rakesh 

Re: generation of taglib doc

[Roland Huss]

<[EMAIL PROTECTED]> writes:

> Can someone tell me how the documentation for the Struts taglibs
> (http://jakarta.apache.org/struts/struts-html.html) is currently
> generated?  I first assumed that this doc was generated from the .tld
> files via XSLT or some other method.  

Nearly correct, but the source documents are not the *.tld files, but
the corresponding *.xml files found in $STRUTS/doc
(e.g. struts-html.xml). Hence, if you like to extend a taglib it is
recommended that you adapt those XML docs and use
$STRUTS/doc/stylesheets/tld.xsl to generate the taglib descriptors and
$STRUTS/doc/stylesheets/struts.xsl to generate the documentation.

Or even better you could use the attached Java class to merge your
extensions into the original Struts tags documents for making update
of Struts less painful. You could use an ant task like 

  
  

 
  
  


  

  

to include the merge into your build process.

cu
-- 
...roland huss
 consol.de


package org.strutsx.util.build;

import java.io.*;

import org.apache.xerces.parsers.DOMParser;

import org.w3c.dom.*;
import org.xml.sax.*;

public class MergeStrutsTaglibDoc { 

	private static DOMParser parser = new org.apache.xerces.parsers.DOMParser();
	
	public static void  main(String args[])
	{
		try
		{
			if (args.length != 3)
			{
System.err.println("Usage: java ...MergeStrutsTaglibDoc " + 
   "  " + 
   "");
System.exit(1);
			}
			
			try 
			{
parser.setFeature( "http://xml.org/sax/features/validation";, true);

			} catch (SAXException e) 
			{
System.out.println("error in setting up parser feature");
			}
			
			// Parse source & ext file
			Document struts_orig = parse(args[0]);
			Document struts_ext =  parse(args[1]);
			String output = args[2];

			
			// Merge (add special tags for extensions)
			NodeList elements = struts_ext.getElementsByTagName("tag");
			for (int i=0;i");

			NodeList children = node.getChildNodes();
			for ( int iChild = 0; iChild < children.getLength(); iChild++ ) 
			{
print(out,children.item(iChild));
			}
			out.flush();
			break;
		}

		// print element with attributes
case Node.ELEMENT_NODE: {
out.print('<');
out.print(node.getNodeName());
NamedNodeMap attrs = node.getAttributes();
for ( int i = 0; i < attrs.getLength(); i++ ) {
Node attr = attrs.item(i);
out.print(' ');
out.print(attr.getNodeName());
out.print("=\"");
out.print(normalize(attr.getNodeValue()));
out.print('"');
}
out.print('>');
NodeList children = node.getChildNodes();
if ( children != null ) {
int len = children.getLength();
for ( int i = 0; i < len; i++ ) {
print(out,children.item(i));
}
}
break;
}

// handle entity reference nodes
case Node.ENTITY_REFERENCE_NODE: {
if ( canonical ) {
NodeList children = node.getChildNodes();
if ( children != null ) {
int len = children.getLength();
for ( int i = 0; i < len; i++ ) {
print(out,children.item(i));
}
}
} else {
out.print('&');
out.print(node.getNodeName());
out.print(';');
}
break;
}

// print cdata sections
case Node.CDATA_SECTION_NODE: {
if ( canonical ) {
out.print(normalize(node.getNodeValue()));
} else {
out.print("");
}
break;
}

// print text
case Node.TEXT_NODE: {
out.print(normalize(node.getNodeValue()));
break;
}

// print processing instruction
case Node.PROCESSING_INSTRUCTION_NODE: {
out.print(" 0 ) {
out.print(' ');
out.print(data);
}
out.println("?>");
break;
}
}

if ( type == Node.ELEMENT_NODE ) {
out.print("');
}
		out.print("\n");
out.flush();
	}

	/** Normalizes the given string. */
private static String normalize(String s) 
	{
StringBuffer str = new StringBuffer();

int len = (s != null) ? s.length() : 0;
for ( int i = 0; i < len; i++ ) {
char ch = s.charAt(i);
switch ( ch ) {
 

RE: digester

[Rey Francois]

Look at the mapper configuration file loading process in the mapper
framework that is available on Ted Husted site (
http://www.husted.com/about/struts/resources.htm#extensions
 ).
See Mappers.initDigester(). I've had to create a few custom rules as well.
Not sure if you can call this a better example. I still think it's overly
complicated but it does the job.
 
Fr

-Original Message-
From: Rakesh [mailto:[EMAIL PROTECTED]]
Sent: 13 July 2001 07:21
To: [EMAIL PROTECTED]
Subject: digester


Is there a better example availiable anywhere of the struts digester than
the struts-config file ?
Any good working examples ?
 
 
 Rakesh 



The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.

http://www.capco.com
***