svn commit: rev 55794 - struts/trunk
Author: craigmcc
Date: Thu Oct 28 00:39:28 2004
New Revision: 55794
Modified:
struts/trunk/build.xml
Log:
Add a dist call to struts-examples/mailreader even though it is not
included in the binary distribution, so that other targets can ultimately
depend on it. Sub-build calls in dist.examples should respect dependency
ordering, so the one for the mail reader APIs should likely remain first.
Modified: struts/trunk/build.xml
==
--- struts/trunk/build.xml (original)
+++ struts/trunk/build.xml Thu Oct 28 00:39:28 2004
@@ -441,10 +441,24 @@
!--
+Build the example standalone modules (even though not yet included)
+--
+target name=dist.examples depends=dist.library
+
+ !-- The Mail Reader Database APIs --
+ antdir=${basedir}/struts-examples/mailreader
+ target=clean inheritAll=false/
+ antdir=${basedir}/struts-examples/mailreader
+ target=dist inheritAll=false/
+
+/target
+
+
+!--
Construct complete binary distribution
--
target name=dist
- depends=dist.library,dist.webapps,dist.source,dist.contrib
+ depends=dist.library,dist.webapps,dist.source,dist.contrib,dist.examples
description=Construct binary distribution/
!--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: rev 55804 - struts/trunk/contrib/struts-shale/src/java/org/apache/shale/impl
Author: husted Date: Thu Oct 28 03:44:07 2004 New Revision: 55804 Modified: struts/trunk/contrib/struts-shale/src/java/org/apache/shale/impl/ImplApplicationFilter.java Log: Correct call to setAttribute method. Modified: struts/trunk/contrib/struts-shale/src/java/org/apache/shale/impl/ImplApplicationFilter.java == --- struts/trunk/contrib/struts-shale/src/java/org/apache/shale/impl/ImplApplicationFilter.java (original) +++ struts/trunk/contrib/struts-shale/src/java/org/apache/shale/impl/ImplApplicationFilter.java Thu Oct 28 03:44:07 2004 @@ -113,7 +113,7 @@ phaseListener = new ImplPhaseListener(); getLifecycle().addPhaseListener(phaseListener); // FIXME - make the mapper pluggable -context.setAttibute(ImplConstants.VIEW_MAPPER, +context.setAttribute(ImplConstants.VIEW_MAPPER, new DefaultViewControllerMapper()); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale. For example, instead of an impl folder, could we have a faces folder? And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the abstract responsibilities of the interface and what happens when an ViewController implementation is wired to JSF? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
How could there be a reason not to do this? (This is not a rhetorical question.) Jack On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale. For example, instead of an impl folder, could we have a faces folder? And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the abstract responsibilities of the interface and what happens when an ViewController implementation is wired to JSF? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: rev 55877 - struts/trunk/contrib/struts-shale
Author: craigmcc
Date: Thu Oct 28 09:52:04 2004
New Revision: 55877
Modified:
struts/trunk/contrib/struts-shale/build.xml
Log:
Tweak what the Ant build script calls this thing to match the
tweaked README.html language.
Modified: struts/trunk/contrib/struts-shale/build.xml
==
--- struts/trunk/contrib/struts-shale/build.xml (original)
+++ struts/trunk/contrib/struts-shale/build.xml Thu Oct 28 09:52:04 2004
@@ -19,7 +19,7 @@
--
-project name=Struts 2.0 'Shale' Proposal default=library basedir=.
+project name=Struts 2.X 'Shale' Proposal default=library basedir=.
!-- = Initialize Property Values --
@@ -36,7 +36,6 @@
property name=jsf.home value=/usr/local/jsf-1_1_01/
property name=junit.home value=/usr/local/junit-3.8.1/
property name=server.home value=/usr/local/jakarta-tomcat-5.0.28/
- property name=struts.home value=/usr/local/jakarta-struts/
!-- Dependency library defaults --
@@ -76,7 +75,7 @@
!-- Build Defaults --
property name=build.home value=${basedir}/target/
property name=dist.home value=${basedir}/dist/
- property name=project.namevalue=Struts 2.0 'Shale' Proposal/
+ property name=project.namevalue=Struts 2.X 'Shale' Proposal/
property name=project.package value=org.apache.shale/
property name=project.version value=0.1-dev/
@@ -150,10 +149,6 @@
echo message=jsf-impl.jar = ${jsf-impl.jar}/
echo message=jsfri.present = ${jsfri.present}/
echo message=myfaces.present= ${myfaces.present}/
-echo message=jsp-api.jar = ${server.home}/common/lib/jsp-api.jar/
-echo message=junit.jar = ${junit.home}/junit.jar/
-echo message=servlet-api.jar = ${server.home}/common/lib/servlet-api.jar/
-echo message=commons-logging.jar = ${commons-logging.jar}/
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale. For example, instead of an impl folder, could we have a faces folder? I don't see the point in doing this now -- if a reasonable non-JSF approach is shown to be viable and accepted by the community we can always do it later. I haven't seen enough yet to make me think this is viable without compromising the simplicity of the current approach. And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the abstract responsibilities of the interface and what happens when an ViewController implementation is wired to JSF? Abstracting when the init/prepare/destroy methods are called and what they do would not be that hard, although you're going to need a bunch of things to make ViewController actually usable without presuming JSF: * The notion of a view identifier that maps to both the view tier presentation (typically a JSP page) and the corresponding ViewController class. * A mechanism for performing validations and handling validation error messages. * Some method that gets invoked when, say, a submit button is pressed that triggers your business logic. * A mechanism for a ViewController to request that its own view get redisplayed, or to navigate to a different view id. All of the above are already provided by JSF, but necessary in a non-JSF world. Basically, I'm really curious how you propose to abstract out the Standard JSF processing and event handling is performed part without essentially re-inventing a JSF-like lifecycle. If you try to impose those abstractions onto the basic ViewController API then I would likely be -1 because they are redundant to using the framework *with* JSF. You could create a NonFacesViewController abstraction on top of ViewController if you wanted, but by that point we might as well create two separate frameworks instead of one. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Struts Shale
Oops ... meant to reply to both Jack and the list. Craig -- Forwarded message -- From: Craig McClanahan [EMAIL PROTECTED] Date: Thu, 28 Oct 2004 10:19:48 -0700 Subject: Re: Struts Shale To: Dakota Jack [EMAIL PROTECTED] On Thu, 28 Oct 2004 06:51:32 -0700, Dakota Jack [EMAIL PROTECTED] wrote: How could there be a reason not to do this? (This is not a rhetorical question.) Ted can correct my understanding of his position if I'm wrong, but basically he wants Struts to be view tier agnostic. I'll agree with that on the actual technology used to implement the dynamic rendering (JSF lets you do that already), but not on abstracting the entire request processing lifecycle. JSF already provides a solid foundation on which to build application level controller facilities, and I see no point in re-inventing that part. Jack Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
Why is it not possible for the framework to use interfaces into which JSF can be plugged in, perhaps with adapters, as an option well as other alternatives? This too is not a rhetorical question. Jack On Thu, 28 Oct 2004 10:16:56 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale. For example, instead of an impl folder, could we have a faces folder? I don't see the point in doing this now -- if a reasonable non-JSF approach is shown to be viable and accepted by the community we can always do it later. I haven't seen enough yet to make me think this is viable without compromising the simplicity of the current approach. And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the abstract responsibilities of the interface and what happens when an ViewController implementation is wired to JSF? Abstracting when the init/prepare/destroy methods are called and what they do would not be that hard, although you're going to need a bunch of things to make ViewController actually usable without presuming JSF: * The notion of a view identifier that maps to both the view tier presentation (typically a JSP page) and the corresponding ViewController class. * A mechanism for performing validations and handling validation error messages. * Some method that gets invoked when, say, a submit button is pressed that triggers your business logic. * A mechanism for a ViewController to request that its own view get redisplayed, or to navigate to a different view id. All of the above are already provided by JSF, but necessary in a non-JSF world. Basically, I'm really curious how you propose to abstract out the Standard JSF processing and event handling is performed part without essentially re-inventing a JSF-like lifecycle. If you try to impose those abstractions onto the basic ViewController API then I would likely be -1 because they are redundant to using the framework *with* JSF. You could create a NonFacesViewController abstraction on top of ViewController if you wanted, but by that point we might as well create two separate frameworks instead of one. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
I think that's Ted's basic point. My answer is to consider how much extra machinery you have to build in to the Struts abstraction of what a ViewController is so that an application built on top of Struts can use different technologies. Just as one example out of my list from the previous email ... how does a ViewController say I want to switch to a new view? With JSF that's easy ... support for navigation is built in based on the string value that's returned by your action mapping, which is processed through the navigation rules that you've defined in faces-config.xml to pick the next view. Without JSF, someone is going to have to build in a way for a ViewController to ask for that -- and that's redundant work. Part of the potential confusion here is based on the fact that JSF isn't just a dynamic rendering technology. Indeed, JSF itself is agnostic whether you want to use JSP pages or Velocity (although you'll need to provide your own ViewHandler plugin for the latter case, but it's not tough to write one). The key difference is that JSF already has a well defined request processing lifecycle built in, following the Front Controller design pattern in a manner fairly similar to the way that Struts currently works. I want to leverage that instead of abstracting it out or reinventing it -- JSF's already good enough. Craig On Thu, 28 Oct 2004 10:23:37 -0700, Dakota Jack [EMAIL PROTECTED] wrote: Why is it not possible for the framework to use interfaces into which JSF can be plugged in, perhaps with adapters, as an option well as other alternatives? This too is not a rhetorical question. Jack On Thu, 28 Oct 2004 10:16:56 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale. For example, instead of an impl folder, could we have a faces folder? I don't see the point in doing this now -- if a reasonable non-JSF approach is shown to be viable and accepted by the community we can always do it later. I haven't seen enough yet to make me think this is viable without compromising the simplicity of the current approach. And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the abstract responsibilities of the interface and what happens when an ViewController implementation is wired to JSF? Abstracting when the init/prepare/destroy methods are called and what they do would not be that hard, although you're going to need a bunch of things to make ViewController actually usable without presuming JSF: * The notion of a view identifier that maps to both the view tier presentation (typically a JSP page) and the corresponding ViewController class. * A mechanism for performing validations and handling validation error messages. * Some method that gets invoked when, say, a submit button is pressed that triggers your business logic. * A mechanism for a ViewController to request that its own view get redisplayed, or to navigate to a different view id. All of the above are already provided by JSF, but necessary in a non-JSF world. Basically, I'm really curious how you propose to abstract out the Standard JSF processing and event handling is performed part without essentially re-inventing a JSF-like lifecycle. If you try to impose those abstractions onto the basic ViewController API then I would likely be -1 because they are redundant to using the framework *with* JSF. You could create a NonFacesViewController abstraction on top of ViewController if you wanted, but by that point we might as well create two separate frameworks instead of one. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31684] - html:frame tag anchor attribute does not appear to pass along correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31684. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31684 html:frame tag anchor attribute does not appear to pass along correctly --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 18:07 --- Checking the HTML 4.01 spec at http://www.w3.org/TR/html4/struct/links.html#h-12.1 appears that HTML still supports the # anchor format (Below is the exert from the spec): Having defined the anchor, we may link to it from the same or another document. URIs that designate anchors contain a # character followed by the anchor name (the fragment identifier). Here are some examples of such URIs: * An absolute URI: http://www.mycompany.com/one.html#anchor-one * A relative URI: ./one.html#anchor-one or one.html#anchor-one * When the link is defined in the same document: #anchor-one Thus, a link defined in the file two.html in the same directory as one.html would refer to the anchor as follows: ...text before the link... For more information, please consult A href=./one.html#anchor-one anchor one/A. ...text after the link... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Struts Shale
On Thu, 28 Oct 2004 13:57:15 -0400, Ted Husted wrote: ... that we rename the package called impl as faces. As to the impl package: I think what really bothers me here is that the classes implemented here are not part of the Shale API. As soon as I saw ImplViewHandler, I starting looking around for a Shale ViewHandler interface. :) Of course, it is not a Shale interface, but a Faces interface. So far, all of the members here extend Faces interfaces or classes. To me, impl says we're implementing the interfaces for the Shale layer (rather than the Faces layer). Naming this package faces clarifies that it contains classes that are dependant on the lower-level Faces API, as opposed to the higher-level Shale API. What I would suggest is that we call the package faces, and the member classes: * ShaleApplicationFilter * ShaleConstants * ShalePhaseListener * ShaleViewHandler I'm thinking that in an import statement * org.apache.shale.ViewController * org.apache.shale.faces.ShaleApplicationFilter would clearly say who's riding whom. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted wrote: On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale. For example, instead of an impl folder, could we have a faces folder? I don't see the point in doing this now -- if a reasonable non-JSF approach is shown to be viable and accepted by the community we can always do it later. I haven't seen enough yet to make me think this is viable without compromising the simplicity of the current approach. And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the abstract responsibilities of the interface and what happens when an ViewController implementation is wired to JSF? Abstracting when the init/prepare/destroy methods are called and what they do would not be that hard, although you're going to need a bunch of things to make ViewController actually usable without presuming JSF: * The notion of a view identifier that maps to both the view tier presentation (typically a JSP page) and the corresponding ViewController class. * A mechanism for performing validations and handling validation error messages. * Some method that gets invoked when, say, a submit button is pressed that triggers your business logic. * A mechanism for a ViewController to request that its own view get redisplayed, or to navigate to a different view id. All of the above are already provided by JSF, but necessary in a non-JSF world. Basically, I'm really curious how you propose to abstract out the Standard JSF processing and event handling is performed part without essentially re-inventing a JSF-like lifecycle. If you try to impose those abstractions onto the basic ViewController API then I would likely be -1 because they are redundant to using the framework *with* JSF. You could create a NonFacesViewController abstraction on top of ViewController if you wanted, but by that point we might as well create two separate frameworks instead of one. What if a component based presentation solution could be found that built on the current features of struts and only focused on the view layer? Struts already has a flavor of managed beans, converters, error messages, localization, actions and declarative navigation rules. JSF provides all of these things in addition. I think it would be interesting to see a solution that was built for struts only focusing on rendering the view but not specifically tied to a single view solution. 1) Restore View Use a custom Request Processor to load a view tree in request scope. The view id could be a simple attribute that was associated with an extended ActionMapping. The view id could be associated with each struts action. The composition of a presentation fragment could be build from a XML source. The XML definitions could define display elements that could act as a container or a component. The definition could support inheritance and composition. Each visual element could be associated with a model class much the same way the action is linked in the struts config. The metadata could be loaded/digested and references fixed up at startup using a plug-in. The resources stored in application scope. 2) Apply Request Values Struts already handle the population of the form bean with values form the request. It handles some data conversion. A system to define unique names for a reusable component mapped into the form bean would be needed. JSF uses at component id which is a name qualified by the containment in the component tree. 3) Process Validation - Struts already provides a declarative validation mechanism. 4) Update Model Values, Invoke Application - A custom view controller could delegate to all the models in the component tree. The view controller, like the LookupDispatchAction and DispatchAction, would need to have a strategy of mapping command to methods or command classes. The component tree would already be staged in request scope from the request processor. The view controller could use the static view definition and create instances of model classes associated with each view element. The controller would need to broadcast too all the model classes. 5) Render Response The action could forward to the view component. The view component would use the component tree metadata and simple helper classes to render the view. The view helper would enumerate metadata and render the view. They could be use in JSP, Custom JSP tags or
Re: Fwd: Struts Shale
On Thu, 28 Oct 2004 14:30:33 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Thu, 28 Oct 2004 13:57:15 -0400, Ted Husted wrote: ... that we rename the package called impl as faces. As to the impl package: I think what really bothers me here is that the classes implemented here are not part of the Shale API. As soon as I saw ImplViewHandler, I starting looking around for a Shale ViewHandler interface. :) Of course, it is not a Shale interface, but a Faces interface. So far, all of the members here extend Faces interfaces or classes. To me, impl says we're implementing the interfaces for the Shale layer (rather than the Faces layer). Naming this package faces clarifies that it contains classes that are dependant on the lower-level Faces API, as opposed to the higher-level Shale API. What I would suggest is that we call the package faces, and the member classes: * ShaleApplicationFilter * ShaleConstants * ShalePhaseListener * ShaleViewHandler I'm thinking that in an import statement * org.apache.shale.ViewController * org.apache.shale.faces.ShaleApplicationFilter would clearly say who's riding whom. Yah, I can buy that argument. Feel free to refactor. By the way, I'm about 50% done with making mailreader work just on top of ViewController (i'll refactor my imports as needed when you make those changes). That will give us a starting point for seeing what applications built on this thing could look like - even without all the dialog and application level stuff. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Struts Shale
Ted Husted wrote: On Thu, 28 Oct 2004 13:57:15 -0400, Ted Husted wrote: ... that we rename the package called impl as faces. As to the impl package: I think what really bothers me here is that the classes implemented here are not part of the Shale API. As soon as I saw ImplViewHandler, I starting looking around for a Shale ViewHandler interface. :) Of course, it is not a Shale interface, but a Faces interface. So far, all of the members here extend Faces interfaces or classes. To me, impl says we're implementing the interfaces for the Shale layer (rather than the Faces layer). Greetings: I have not had a chance to look at the Shale API yet, but i already play around with the idea of controller and adapters. To me, the view handler (either you use JSF which is available now or future framework) is only 1 part of the adapters to manage services that use HTTP/HTTPS ports. Other services that use the ports are WebService, WebDAV, JMXRemote. It makes sense for Shale API to handle all standard services using HTTP/HTTPS by providing a centralized service requester and service router that routes the incoming services to appropriate adapter (view adapter for browser and mobile devices, webService adapter, webDAV adapter and JMXRemote adapter). Is there any one thinking along this line? BaTien DBGROUPS Naming this package faces clarifies that it contains classes that are dependant on the lower-level Faces API, as opposed to the higher-level Shale API. What I would suggest is that we call the package faces, and the member classes: * ShaleApplicationFilter * ShaleConstants * ShalePhaseListener * ShaleViewHandler I'm thinking that in an import statement * org.apache.shale.ViewController * org.apache.shale.faces.ShaleApplicationFilter would clearly say who's riding whom. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
I admit to a huge amount of ignorance about JSF. I have partly been stymied by an inability to decide on a text to read. I have always liked Hans work, and may go that direction. I cannot know, of course, how that ignorance impacts my part in this discussion. I do think that in any event it is wise for shale to accommodate but not be tied to a particular implementation, if there is no penalty for that, and I cannot see one. I have always found that allowing options in the long run. Jacki On Thu, 28 Oct 2004 14:06:32 -0500, Joe Germuska [EMAIL PROTECTED] wrote: The focus of the visual component base solution would be to create a XML definition, backed beans, and an abstract factory/ cache to manage the resources. Create a view controller or action class that knows how to use the metadata to manage corresponding model classes. And view helpers that would encapsulate the call back to the models when generating a presentation. It's not as sexy as faces? Thanks for listening ti What you describe still sounds like it's essentially rewriting Faces-type functionality. I think I'm warming up to Craig's point. The only reason we shouldn't use JSF is if we don't like the processing model it provides. If we like the processing model it provides, we shouldn't go to the trouble to rewrite it. Folks who want to do that can work on the MyFaces implementation instead. My JSF experience is still limited to reading about it. I find it pretty interesting. I've read some commentary that pegs it as overkill, but haven't reached that conclusion myself. I'd be better off talking about it if I'd used it more. The point being that JSF stakes out a lot of territory for the view-side of the equation. Craig's deep familiarity with it makes it a natural way for him to envision the view-controller side of Shale. If people think it's not a good solution to the view-controller side, then they should articulate why -- and even if the why is just i'd rather not buy into JSF yet, then they should come up with an alternate description of the view controller's responsibilities. Then people can make a choice based on how it works rather than what its called. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale - Itch Proposal
On Wed, 27 Oct 2004 16:34:51 -0400, Ted Husted [EMAIL PROTECTED] wrote: Instead of taking the approach of predicting what developers might want from Struts and JSF in the future You probably have little to worry about in this regard, Scott. :) Really? I am glad to hear that Shale will be efficiently solving all my future web application development problems. I can now rest easy. :) Few, if any of us, are doing this for fun or profit. I would recommend that you try doing stuff for fun and profit. It has worked for me. We do Struts, and would do Shale, because we want to use the frameworks in our applications. Which, I imagine, are much like yours :) If your applications are like mine then why are you not thinking of how you can be more productive in building your apps via the sharing of and collaborating on reusable application components, in addition to leveraging the very slim framework currently known as Struts. For the most part, the development of Struts and Shale is driven by what we need to do in our own applications. Are these applications innovative? Can this innovation be shared? My suggestion of a reference application for Shale that also served as an authoring tool for applications running on the framework was motivated in part by hopes for it becoming a proving ground for innovative approaches that could be adopted and built upon. But, do keep in mind that we are all working developers here. Most of us are already writing applications full-time (at least I am), and then working on the framework at night :) The basis of this proposal was to suggest an efficient and productive approach to get wherever you (and hopefully most everyone else) want to go. If the investment in a 1st class reference application and reusable common application components is proven an inefficient use of resources then I would like to understand why. I firmly believe taking the approach of identifying what type of application meets the needs of the Struts developer community, identifying what kinds of tools would be useful for this development process, develop a production release of the sample application along with tools that demonstrated enhanced productivity, and *then* culling off reusable components as the framework layer could be a successful and efficient process. Incidentally, the idea behind the Struts SourceForge site was to host community applications. Perhaps this will be a chance to get back to doing that again. What is currently lacking from the original vision for this repository? The application you mention at the end of your post seems ambitious, but some Starter Kits would be a very good idea. Our friends at ASP.NET offer several. My thought was that it should be ambitious in scope to demonstrate a complete solution that could easily be simplified during the developer's repurposing of the reference application. My thinking is related to my observations of how Eclipse and Netbeans are becoming reference applications in addition to their primary function of being IDEs. The tool I alluded to does not have to be a full blown IDE from its inception. Its first iteration could be a web application or service that spit out a WAR that could be used to assemble a slide show application. If that first step were taken by leveraging a portion of the Netbeans code base that is sitting in your web app's /WEB-INF/lib/ directory, then you have some confidence in succeeding with the evolving of this simple app to whatever a hosted browser-based IDE UI should look and behave like. Scott __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Shale
I have to agree with Craig here. Although I haven't used JSF that much yet, I have investigated it enough to understand its basic infrastructure and functionality. As Craig said, it would require much work to abstract the same functionality in to Struts, where it is already available in JSF (such as view navigation). One of my personal wishes for Struts 2.x (and I would love to volunteer) is a smooth and clear integration with JSF. Many people are confused about how JSF fits in with frameworks such as Struts (and webapps in general), and this would be a great opportunity to clear that up once and for all. Besides, it would put us in a good position marketing-wise, as there aren't currently any frameworks (to mine knowledge anyway) utilizing JSF in this manner. Shale should then focus on adding neat features outside of what JSF already does. I do wonder about one thing though - how would portlets fit into all this? I know next to nothing about portlets, except that I feel it should be supported out-of-the-box in Struts 2.x. Could JSF be used in that regard? Regards, \Anders -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: 28. oktober 2004 19:40 To: Dakota Jack; Struts Developers List Subject: Re: Struts Shale I think that's Ted's basic point. My answer is to consider how much extra machinery you have to build in to the Struts abstraction of what a ViewController is so that an application built on top of Struts can use different technologies. Just as one example out of my list from the previous email ... how does a ViewController say I want to switch to a new view? With JSF that's easy ... support for navigation is built in based on the string value that's returned by your action mapping, which is processed through the navigation rules that you've defined in faces-config.xml to pick the next view. Without JSF, someone is going to have to build in a way for a ViewController to ask for that -- and that's redundant work. Part of the potential confusion here is based on the fact that JSF isn't just a dynamic rendering technology. Indeed, JSF itself is agnostic whether you want to use JSP pages or Velocity (although you'll need to provide your own ViewHandler plugin for the latter case, but it's not tough to write one). The key difference is that JSF already has a well defined request processing lifecycle built in, following the Front Controller design pattern in a manner fairly similar to the way that Struts currently works. I want to leverage that instead of abstracting it out or reinventing it -- JSF's already good enough. Craig On Thu, 28 Oct 2004 10:23:37 -0700, Dakota Jack [EMAIL PROTECTED] wrote: Why is it not possible for the framework to use interfaces into which JSF can be plugged in, perhaps with adapters, as an option well as other alternatives? This too is not a rhetorical question. Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Shale
I have to agree with Craig here. Although I haven't used JSF that much yet, I have investigated it enough to understand its basic infrastructure and functionality. As Craig said, it would require much work to abstract the same functionality in to Struts, where it is already available in JSF (such as view navigation). One of my personal wishes for Struts 2.x (and I would love to volunteer) is a smooth and clear integration with JSF. Many people are confused about how JSF fits in with frameworks such as Struts (and webapps in general), and this would be a great opportunity to clear that up once and for all. Besides, it would put us in a good position marketing-wise, as there aren't currently any frameworks (to mine knowledge anyway) utilizing JSF in this manner. Shale should then focus on adding neat features outside of what JSF already does. I do wonder about one thing though - how would portlets fit into all this? I know next to nothing about portlets, except that I feel it should be supported out-of-the-box in Struts 2.x. Could JSF be used in that regard? Regards, \Anders -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: 28. oktober 2004 19:40 To: Dakota Jack; Struts Developers List Subject: Re: Struts Shale I think that's Ted's basic point. My answer is to consider how much extra machinery you have to build in to the Struts abstraction of what a ViewController is so that an application built on top of Struts can use different technologies. Just as one example out of my list from the previous email ... how does a ViewController say I want to switch to a new view? With JSF that's easy ... support for navigation is built in based on the string value that's returned by your action mapping, which is processed through the navigation rules that you've defined in faces-config.xml to pick the next view. Without JSF, someone is going to have to build in a way for a ViewController to ask for that -- and that's redundant work. Part of the potential confusion here is based on the fact that JSF isn't just a dynamic rendering technology. Indeed, JSF itself is agnostic whether you want to use JSP pages or Velocity (although you'll need to provide your own ViewHandler plugin for the latter case, but it's not tough to write one). The key difference is that JSF already has a well defined request processing lifecycle built in, following the Front Controller design pattern in a manner fairly similar to the way that Struts currently works. I want to leverage that instead of abstracting it out or reinventing it -- JSF's already good enough. Craig On Thu, 28 Oct 2004 10:23:37 -0700, Dakota Jack [EMAIL PROTECTED] wrote: Why is it not possible for the framework to use interfaces into which JSF can be plugged in, perhaps with adapters, as an option well as other alternatives? This too is not a rhetorical question. Jack - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Shale
3.1 Java2 Standard Edition APIs I'd be +1 for J2SE 5.0 Although I have no real saying in this, I am +1 on J2SE 5.0 as well. As I would anticipate 1-2 years in development on Struts 2.x, J2SE 5.0 should be widely deployed by then. If not, then our endorsement of it could encourage people to make the switch. ;) Plus, it could stand as a marketing bonus - in support of our revolutionary path. Quick questions regarding Commons Logging proposal: Letting people choose their logging implementation is not a bad idea, but I've been hearing negative things about Commons Logging in its ability to detect the correct implementation to use. Something about classpath problems, if I remember correctly? Are these issues solved? Again, this is just little me's two cents, but I am in favor of minimizing third party dependencies as much as possible, and I don't see very much reason not to use the JDK 1.4 implementation. Anyone? Regards, \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Shale
3.1 Java2 Standard Edition APIs I'd be +1 for J2SE 5.0 Although I have no real saying in this, I am +1 on J2SE 5.0 as well. As I would anticipate 1-2 years in development on Struts 2.x, J2SE 5.0 should be widely deployed by then. If not, then our endorsement of it could encourage people to make the switch. ;) Plus, it could stand as a marketing bonus - in support of our revolutionary path. Quick questions regarding Commons Logging proposal: Letting people choose their logging implementation is not a bad idea, but I've been hearing negative things about Commons Logging in its ability to detect the correct implementation to use. Something about classpath problems, if I remember correctly? Are these issues solved? Again, this is just little me's two cents, but I am in favor of minimizing third party dependencies as much as possible, and I don't see very much reason not to use the JDK 1.4 implementation. Anyone? Regards, \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Thu, 28 Oct 2004 15:27:49 -0700, Dakota Jack [EMAIL PROTECTED] wrote: I admit to a huge amount of ignorance about JSF. I have partly been stymied by an inability to decide on a text to read. I have always liked Hans work, and may go that direction. I cannot know, of course, how that ignorance impacts my part in this discussion. I do think that in any event it is wise for shale to accommodate but not be tied to a particular implementation, if there is no penalty for that, and I cannot see one. I have always found that allowing options in the long run. A particular implementation of JSF, or a particular view technology in general? You don't have to worry about the former ... we'd be coding solely to JSF standard APIs, so you can use the JSF RI, MyFaces (once they fix a few outstanding bugs that mess up struts-faces too :-), or anyone else's conforming implementation. Choosing to rely or not rely on JSF's request processing lifecycle has huge impact on the design of Shale ... basically for everything that JSF already does that we want to keep, we'd have to define our own abstraction and then enforce that contract on any other technology. The simplest example is navigating from one page to another -- if you can't assume JSF underneath, then ViewController (or something) needs some additional API to do that. Regarding JSF information, I have read and can vouch for Hans Bergsten's and David Geary's JSF books. I haven't had time to read some of the others, but I've met some of the authors and it seems likely that they'll be high quality as well. A good starting bookmark for your browsing pleasure is http://jsfcentral.com, which has links to lots and lots of resources about JSF. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Fri, 29 Oct 2004 01:22:09 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: 3.1 Java2 Standard Edition APIs I'd be +1 for J2SE 5.0 Although I have no real saying in this, I am +1 on J2SE 5.0 as well. As I would anticipate 1-2 years in development on Struts 2.x, J2SE 5.0 should be widely deployed by then. If not, then our endorsement of it could encourage people to make the switch. ;) Plus, it could stand as a marketing bonus - in support of our revolutionary path. I sure hope it doesn't take us 1-2 years, but with our track record I'd be pretty foolish to make any promises at this point :-). Quick questions regarding Commons Logging proposal: Letting people choose their logging implementation is not a bad idea, but I've been hearing negative things about Commons Logging in its ability to detect the correct implementation to use. Something about classpath problems, if I remember correctly? Are these issues solved? 99.9% of the issue is configuration -- getting the right JARs and configuration files in the right place. In that sense its not really different than any other JAR that might be included in the webapp or installed in the container. You just need to get all the moving parts where they belong. And use C-L 1.0.4 or later, of course, because there were some critical bugfixes. Struts 1.x has used C-L from the very beginning of its existence, and we've been satisfied with it. Again, this is just little me's two cents, but I am in favor of minimizing third party dependencies as much as possible, and I don't see very much reason not to use the JDK 1.4 implementation. Anyone? There are a lot of potential customers that have existing environments based on things like Log4J, and those folks would be really (and justifiably) irritated to be required to configure two logging systems. Regards, \Anders Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
At 3:27 PM -0700 10/28/04, Dakota Jack wrote: I admit to a huge amount of ignorance about JSF. I have partly been stymied by an inability to decide on a text to read. I have always liked Hans work, and may go that direction. I cannot know, of course, how that ignorance impacts my part in this discussion. I do think that in any event it is wise for shale to accommodate but not be tied to a particular implementation, if there is no penalty for that, and I cannot see one. I have always found that allowing options in the long run. Particular implementation of what? View renderer? JSF can use Velocity to render its views, so it's not tied to JSP as the implementation of a view renderer. View controller? JSF is an API, so you aren't tied to the reference implementation. In fact, there is an Apache incubator project (MyFaces) to build an alternative implementation: http://incubator.apache.org/projects/myfaces.html Of course, there is no more generalized view controller API right now. Craig's point is that it would be substantially reinventing the wheel to design yet another API and implementation when JSF seems to address all the bases. Craig is starting from his knowledge of JSF and proscribing it as a facility for providing a lot of functionality to Shale. If anyone cares to start from the other side and describe the functionality Shale needs, and finds that they don't end up essentially describing JSF, then we'd have something to choose between. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
Craig is starting from his knowledge of JSF and proscribing it as a facility for providing a lot of functionality to Shale. er... prescribing. Sorry. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31922] - Pluggable MultipartRequestWrapper
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31922. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31922 Pluggable MultipartRequestWrapper --- Additional Comments From [EMAIL PROTECTED] 2004-10-29 04:44 --- You can already use a different multipart implementation by providing your own implementation of the MultipartRequestHandler interface. Is this not what you need? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: rev 55793 - in struts/trunk/struts-examples: mailreader mailreader-database
Author: craigmcc Date: Thu Oct 28 00:29:18 2004 New Revision: 55793 Added: struts/trunk/struts-examples/mailreader/ - copied from rev 55792, struts/trunk/struts-examples/mailreader-database/ Removed: struts/trunk/struts-examples/mailreader-database/ Log: Move struts-examples/mailreader-database to struts-examples/mailreader. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
