Patch for Bug #1598
To all committers, I would like to ask one of the committers to submit the patch I attached to this mail for bug #1598. It adds a wrap attribute to the struts-html tag textarea. The bug was assigned to Craig, but I don't know if he is around. So could someone please incorporate this minor fix. The files that need to be changed are: src/share/org/apache/struts/taglib/html/BaseInputTag.java src/share/org/apache/struts/taglib/html/TextareaTag.java doc/struts-html.xml I would appreciate if you could drop me a short mail, when this fix is incorporated. Thanks, --- Matthias BaseInputTag.txt TextareaTag.txt struts-html.txt S/MIME Cryptographic Signature
Re: JXPath: use xpath to access JavaBeans
Hi Dmitri From: Dmitri Plotnikov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 01, 2001 3:50 PM Subject: JXPath: use xpath to access JavaBeans Check out JXPath, a bridge between XPath and JavaBeans: http://www.plotnix.com/jxpath The basic idea is to use the XPath syntax to access/modify properties of java beans. Normally XPath is applied to DOM trees. JXPath makes it work with graphs of JavaBeans, primitive types, collections, arrays and maps. This is really cool. I had a similar idea recently and started a thread on the jakarta-commons list. http://www.mail-archive.com/jakarta-commons%40jakarta.apache.org/msg01460.ht ml I can see an XPath syntax expression language really useful across all JSP tag libraries. Using a single XPath expression language to query across DOM-ish trees (DOM, dom4j, JDOM, Electric XML etc.) or JavaBeans would be really cool. Right now I use a JSP tag library I wrote called xtags (http://xtags.org) to style and format XML documents using XSLT-like tags and XPath expressions. (Hopefully it will be added to the jakarta-taglibs project real soon now). It is quite simple to build complex pages just using a just simple set of tags and XPath expressions. It would be cool if a similar technique could be done to query Java Beans as well as XML object models. This could lead to an interesting prototyping technique. As you start building your web-app write static XML documents to represent you 'bussiness object models' state. Then use XPath and JSP custom tags to create the view JSPs of your business objects that you need. That way you learn what business object state you need in your XML document. Then you can turn the static XML into real data either by generating the XML dynamically, or by implementing a set of Java Beans which match the XPath expressions you need. Another approach would be to use XSLT to style your existing Java Bean business objects. I notice that your JXPath implementation implements the DOM API as a proxy so Java Beans can work with Xalan. This is a neat idea. Fancy donating it to Jakarta? ;-) I'd like to use JXPath to integrate into xtags so that xtags could work on XML or Java Beans. For a variety of reasons I'm also considering starting a JPath project that does it the other way around - open up an existing XPath engine (say, Xalan) and refactors the code such that more efficient bindings can be done to say:- * DOM * Java Beans (Map, Collection, Arrays etc) * dom4j * JDOM * Electric XML Certainly the dom4j and JDOM communities would also benefit from having a native (say) Xalan's XPath engine bound to their object models, without having to make intermediate DOM adapter objects. Having Java Beans bindings would be really cool too. Would you be interested in getting involved in that too, if ever it gets off the ground? James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Per-Populating Form (Take 2)
Hi All,
I had previously posted a mail about prepopulating the
form before it is presented to the user.
My take on this is :
1.ActionForm will have a method called
init(HttpServletRequest req).
In this init method we can use any request parameters
to initilize the form the very first time like this
public void init(ActionMapping mapping ,
HttpServletRequest request)
{
if (! initialized) {
doInit(mapping,request);
initialized = true;
}
}
doInit() will be app specific method for prepopulating
the form before presenting it to user.
2.Action Servlet will need an extra line to accomodate
this.
In the processPopulate method the last line would be
formInstance.init(mapping,request)
Does this sound reasonable to folks ?
Or am I being a moron and there is some other way of
acheving this ?
Your suggestions are welcome.
Srikanth
__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
Re: Per-Populating Form (Take 2)
On Thu, 3 May 2001, Open Source wrote:
Hi All,
I had previously posted a mail about prepopulating the
form before it is presented to the user.
My take on this is :
1.ActionForm will have a method called
init(HttpServletRequest req).
In this init method we can use any request parameters
to initilize the form the very first time like this
public void init(ActionMapping mapping ,
HttpServletRequest request)
{
if (! initialized) {
doInit(mapping,request);
initialized = true;
}
}
doInit() will be app specific method for prepopulating
the form before presenting it to user.
2.Action Servlet will need an extra line to accomodate
this.
In the processPopulate method the last line would be
formInstance.init(mapping,request)
Does this sound reasonable to folks ?
Or am I being a moron and there is some other way of
acheving this ?
While this technique could work, I tend to prefer a different approach,
based on the philosophy that pre-populating a form requires business
logic.
Consider the approach used in the example application, when you are on the
registration.jsp page and you want to edit one of the subscriptions. What
happens is:
* The hyperlink goes to the /editSubscription action,
passing the primary key information as request parameters.
* The /editSubscription action looks up the corresponding
subscription in the database (and returns an error if this
fails, which is tough to do in the init method of a form bean).
* The /editSubscription action instantiates a form bean,
populates its values from the underlying database information,
and places it in the appropriate scope.
* The /editSubscription action forwards to the subscription.jsp
page.
* The subscription.jsp page finds the form bean pre-populated with
the relevant information for the selected subscription.
This technique also keeps the form beans themselves simpler -- they don't
have to know how to read their own information from the database, or
access the appropriate EJBs, or whatever. They stick to their purpose in
life, which is to be the server-side representation of the input fields on
a form.
Your suggestions are welcome.
Srikanth
Craig McClanahan
RE: Per-Populating Form (Take 2)
my $0.02 thought...
Why don't U just inititlaize the form in the ActionHandler?
Uday
-Original Message-
From: Open Source [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 03, 2001 11:27 AM
To: [EMAIL PROTECTED]
Subject: Per-Populating Form (Take 2)
Hi All,
I had previously posted a mail about prepopulating the
form before it is presented to the user.
My take on this is :
1.ActionForm will have a method called
init(HttpServletRequest req).
In this init method we can use any request parameters
to initilize the form the very first time like this
public void init(ActionMapping mapping ,
HttpServletRequest request)
{
if (! initialized) {
doInit(mapping,request);
initialized = true;
}
}
doInit() will be app specific method for prepopulating
the form before presenting it to user.
2.Action Servlet will need an extra line to accomodate
this.
In the processPopulate method the last line would be
formInstance.init(mapping,request)
Does this sound reasonable to folks ?
Or am I being a moron and there is some other way of
acheving this ?
Your suggestions are welcome.
Srikanth
__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
Clarification on behavior of bean:include
Consider the following JSP Pages
Main.jsp
%@ taglib uri=bean prefix=bean %
bean:define id=poweredbyTitle
value=h2Economic Report By County/h2
toScope=request /
jsp:include page=PoweredBy.jsp flush=true/
PoweredBy.jsp
-
%@ taglib uri=bean prefix=bean %
bean:write name=poweredbyTitle filter=false/
Is Powered By...
The 'bean:write' is able to find 'poweredbyTitle' in
request scope. However, if I use the following 'Main.jsp'
page with 'bean:include':
Main.jsp2
---
%@ taglib uri=bean prefix=bean %
bean:define id=poweredbyTitle
value=h2Economic Report By County/h2
toScope=request /
bean:include id=poweredby forward=poweredby /
Assuming correct Global Forward...the 'PoweredBy.jsp' page
is not able to locate find the attribute 'poweredbyTitle'
in any scope (as far as I can tell), and an empty String
is printed. Note that if I use (in Main.jsp)
'toScope=session' instead, it all works fine.
Is this the expected behavior, or a bug? (I'll make the
appropiate bug-report if necessary.)
Thanks,
Gidado
p.s. From looking at org.apache.struts.taglib.IncludeTag:
public int doStartTag() throws JspException {
URL url = hyperlink();
URLConnection conn = null;
try {
conn = url.openConnection();
conn.setAllowUserInteraction(false);
conn.setDoInput(true);
conn.setDoOutput(false);
conn.connect();
it is apparent that there is no use of a RequestDispatcher
(which, I'm assuming, would help in keeping track of
'request' scoped attributes).
Re: Clarification on behavior of bean:include
Unfortunately, you won't be able to use request scope for this. The
reason is that, in a JSP 1.1 environment, bean:include has to internally
do a separate request in order to buffer the output. Because it is a
separate request, request scope attributes are not shared.
Once we can migrate to Servlet 2.3 / JSP 1.2, it will be possible to
implement bean:include so that is shares the same request.
Craig
On Thu, 3 May 2001, Immanuel, Gidado-Yisa wrote:
Consider the following JSP Pages
Main.jsp
%@ taglib uri=bean prefix=bean %
bean:define id=poweredbyTitle
value=h2Economic Report By County/h2
toScope=request /
jsp:include page=PoweredBy.jsp flush=true/
PoweredBy.jsp
-
%@ taglib uri=bean prefix=bean %
bean:write name=poweredbyTitle filter=false/
Is Powered By...
The 'bean:write' is able to find 'poweredbyTitle' in
request scope. However, if I use the following 'Main.jsp'
page with 'bean:include':
Main.jsp2
---
%@ taglib uri=bean prefix=bean %
bean:define id=poweredbyTitle
value=h2Economic Report By County/h2
toScope=request /
bean:include id=poweredby forward=poweredby /
Assuming correct Global Forward...the 'PoweredBy.jsp' page
is not able to locate find the attribute 'poweredbyTitle'
in any scope (as far as I can tell), and an empty String
is printed. Note that if I use (in Main.jsp)
'toScope=session' instead, it all works fine.
Is this the expected behavior, or a bug? (I'll make the
appropiate bug-report if necessary.)
Thanks,
Gidado
p.s. From looking at org.apache.struts.taglib.IncludeTag:
public int doStartTag() throws JspException {
URL url = hyperlink();
URLConnection conn = null;
try {
conn = url.openConnection();
conn.setAllowUserInteraction(false);
conn.setDoInput(true);
conn.setDoOutput(false);
conn.connect();
it is apparent that there is no use of a RequestDispatcher
(which, I'm assuming, would help in keeping track of
'request' scoped attributes).
