Actually, I just wrote a web application that uses Struts 1.2.4, Struts
Flow - http://struts.sf.net/flow , iBATIS database layer, and a touch of
Java. Struts Flow allows you to use a Javascript function to replace a
Struts action. I use iBATIS to run SQL queries and return Lists of Maps
(a Ma
I didn't see anything in that proposal that couldn't be satisfied by
Struts Flow, but I could have missed something. If so, we could
supplement Struts Flow to support it. Converting Javascript objects to
Maps should be a sufficient way to handle compatibility with existing
Struts capabilities
Hmm...good question. :) Struts BSF is a very simple project that lets
you write a Struts action using a BSF-supported scripting language. The
advantage of this project is you can use any BSF-compatible language
including Python, Ruby, Groovy, Javascript, Perl and even VBScript (on
windows).
r, where a server side object would attempt to map that
into a server side class?
Hubert
On Fri, 29 Oct 2004 13:45:34 -0700, Don Brown <[EMAIL PROTECTED]> wrote:
Actually, I just wrote a web application that uses Struts 1.2.4, Struts
Flow - http://struts.sf.net/flow , iBATIS database layer, and
Hey, I'll could do that this weekend, but I thought I was to wait until
1.2.5 was rolled, which has, well, stalled. Damn you and your dark,
velvety carrot. :)
Don
Ted Husted wrote:
On Fri, 29 Oct 2004 14:01:36 -0700, Don Brown wrote:
Struts Flow will be added to Struts soon as an off
On Fri, 29 Oct 2004 23:52:49 -0400, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> Argh, posted to the wrong list!
>
> Well, in all honesty, this isn't something that was initiated by me,
> I've never had a thought of passing objects back and forth, so I'm not
> sure I can give you a real, concret
ects. Assuming that's not it though, can you point me
> in the right direction? I'm most definitely interested!
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> Don Brown wrote:
> > On
Perhaps this has already been discussed, but I couldn't find anything
about it
How will we organize Struts subprojects in the repository? As I
understand it, Struts subprojects are projects that are intimately
associated with Struts, yet have their own release cycle. The prime
example being
No, actually, it would be a simple matter of a couple of "svn move"
commands. They are quick, and can be easily redone later if we change
our minds.
Don
On Fri, 5 Nov 2004 07:42:44 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 9:52 PM -0800 11/4/04, Don Brown wrot
://svn.apache.org/asf/struts/core/trunk
Don
Craig McClanahan wrote:
On Fri, 5 Nov 2004 08:01:33 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
No, actually, it would be a simple matter of a couple of "svn move"
commands. They are quick, and can be easily redone later if we change
our minds.
it. Otherwise, I think we need to consider it a bit
> more.
>
> --
> Martin Cooper
>
>
>
>
> On Fri, 05 Nov 2004 15:26:45 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
> > In a perfect world...
> >
> > svn.apache.org/asf/struts
> > /c
Yes. :)
Don
On Mon, 8 Nov 2004 12:08:35 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On Mon, 8 Nov 2004 11:50:43 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
> >
> >
> > I'm not sure what you mean and how refactoring is enhanced by using one
>
As you many have noticed, we've reorganized the Struts as discussed,
moving core Struts code as its own "subproject", then giving struts-faces
and struts-el their own "subproject". At the same time, due to core build
requirements concerning struts-el, we moved struts-el to its own
"subproject".
I
I've developed a quite small patch that allows Struts, Validator, and
Tiles configuration files to be loaded from the classloader if not
found in the servlet context. This allows people to distribute Struts
modules as self-contained jars (save jsp's of course if the module
uses those).
The previo
+1 and I'll assist in knocking the remaining bugs down or anything else
necessary.
Don
> If everything else is resolved, I don't think we need to wait on Validator
> 1.1.4. If it's ready when we are, fine. If not, #18169 does not seem like
> a "showstopper" issue to me, and we can finish impleme
Joe Germuska wrote:
Where would ActionCommand fit in, more specifically? Is the idea that
you'd rig the chain to use a different command that fills the general
role of the current "ExecuteAction" command? Did you guys come up
with more specific APIs for the ActionContext and ViewContext?
The b
Perhaps this might be a good time to bring up the idea of bringing
StrutsTestCase as a Struts subproject? They have an implementation of
the servlet api for testing.
Don
Joe Germuska wrote:
I just found an annoying bug in struts-chain, where CreateAction was
looking up the map of actions under
The bottom line is Struts now uses xml configuration as declarative
configuration, rather than procedural. We define forms, actions,
plugins, etc., without defining a process for using them.
When you start looking at configuration for defining procedures, it can
get messy quick - just look at
Comments inline...
Joe Germuska wrote:
I think Martin said chain is in trunk.
I would assume that the nighly bulids would then have chain in
there, and that it not be a separate download?
Chain is not yet in the core, but getting it there is something I'm
interested in working on. It may also
Doh, right, forgot about that :) How about both -
WEB-INF/chain-config.xml first, then /chain-config.xml for easier
embedding in the jar?
Don
Craig McClanahan wrote:
On Tue, 23 Nov 2004 09:58:11 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
Sounds good. I would take it a step furthe
Not you personally BaTien, I don't understand why some people seem to
confuse Inversion of Control (IoC) and Chain of Responsibility (CoR),
and worse, think they are somehow solving the same problem. IoC helps
us create components by managing their lifecycle and providing their
dependencies.
een CoR and IoC that is not as
attenuated as the one between HashMap and a SQL database but more like
a properties file and a SQL database? You think?
Jack
On Wed, 24 Nov 2004 10:44:30 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
Not you personally BaTien, I don't understand why some people
How would this work with digester? As I understand it, digester is the
one that actually populates the action config, and then only at init time.
I sure like the idea, but don't know about the naming style. What about
foo.bar where foo corresponds to setFoo(Map m) and foo.bar calls
m.put("ba
struts-config.xml accomplishes the following tasks:
1. Defines form models
2. Defines and configures Actions
3. Defines and configures mappings of actions
4. Defines and configures plugins
5. Defines and configures message resources
6. Defines and configures request processor
I see Spring vastly im
p to 5 different configuration files
better for the user? If I was put in this position, I would seriously
consider other ways of writing Java webapps.
David
Craig
On Mon, 29 Nov 2004 10:03:16 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
struts-config.xml accomplishes the followin
Is not Spring MVC (which is very much like Struts) configured from a
Spring configuration file?
Ideally, an application should be able to use as many, or as few,
configuration files as it likes.
-Ted.
On Mon, 29 Nov 2004 10:47:07 -0800, Don Brown wrote:
Good point, however the use of intel
Very applicable actually :)
Let's look it this way - what types of information needs to go into
configuration? I see the following types:
1. Action/Backing bean definitions. Perferably support for connecting
with business objects.
2. Form/field definitions and validations.
3. ActionForwards/Nav
On the topic of a Struts API bean, I completely agree. We should have
one bean, probably actually stored in the servlet context, which
contains references to all the Struts-specific components like
configuration elements and message resources. Now this, and the Spring
topic, do overlap since
Sure, works for me :)
Don
Joe Germuska wrote:
Now, then: This whole thread started as a different question and was
motivated by an earlier question. Assuming that we continue to use
Digester to instantiate and populate ActionConfig objects, I would
like to add a "generic" mapped property to A
e start the revolution!)
-Ted.
On Tue, 30 Nov 2004 16:00:49 -0800, Don Brown wrote:
On the topic of a Struts API bean, I completely agree. We should
have one bean, probably actually stored in the servlet context,
which contains references to all the Struts-specific components
like configuration e
As I understand it, the key to improving the build, be it Maven or Ant,
is who will get the job done. There used to be quite a bit of interest
in a Maven build, and some progress was made toward a conversion,
however, the work was never completed. If someone stepped up and
completed the Maven
The summary of our discussion, as I understand it, would be to create a
ActionContext, which would not be a subclass of any commons-chain
contexts, but would contain the commons-chain, probably WebContext
instance available via a getter. This would allow us to have one
ActionContext instance,
context, would it not let you just do the same thing you said bellow?
(and w/o servlet api).
.V
Don Brown wrote:
The summary of our discussion, as I understand it, would be to create
a ActionContext, which would not be a subclass of any commons-chain
contexts, but would contain the commons-chain
I added the struts-bsf as a Struts subproject, and am now looking to
create a website for it to add to the Struts site. How should I go
about this? Will it be built with Anakia? Should it be created as part
of the Struts site build?
Thanks for the help.
Don
-
Martin Cooper wrote:
On Thu, 16 Dec 2004 21:18:16 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
I added the struts-bsf as a Struts subproject,
Strange - the only commit message I've seen is the one to remove
.cvsignore files. I would have expected to see an add message...
Who is working on bringing Struts chain into Struts core? If no one, I
wouldn't mind doing the integration.
I'm thinking about using the ComposableRequestProcessor to keep as much
backwards compatibility as possible. The changes I'm proposing by layer:
web.xml
- A "chainConfig" parameter to
I'm setting up Struts to build from Ant (again), and have to go through
the hassle of setting up build.properties. When I brought struts-bsf
in, I changed its build.xml to, if a "lib" directory didn't exist,
create one and use Ant's get task to pull the jars from ibiblio. It
wouldn't be a lon
Martin Cooper wrote:
On Thu, 16 Dec 2004 21:47:53 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
Who is working on bringing Struts chain into Struts core? If no one, I
wouldn't mind doing the integration.
I've been wondering the same thing. I have not done anything myself
yet, so
her build stuff I want to clean up before I commit
that. (Last night's Cactus property clean-up was part of that.)
--
Martin Cooper
On Thu, 16 Dec 2004 22:10:50 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
I'm setting up Struts to build from Ant (again), and have to go through
the hassl
id for BSF Scripting. Is the website updated by
some cron job, or does a committer have to refresh it?
Don
-Ted.
On Thu, 16 Dec 2004 21:18:16 -0800, Don Brown wrote:
I added the struts-bsf as a Struts subproject, and am now looking
to create a website for it to add to the Struts site. H
Author: mrdon
Date: Thu Dec 16 21:24:23 2004
New Revision: 122615
URL: http://svn.apache.org/viewcvs?view=rev&rev=122615
Log:
Adding struts-bsf at version 0.5-dev with adjustments to remove need
to store jars in repository
Added:
struts/bsf/
struts/bsf/.cvsignore
struts/bsf/branches/
struts
Personally, I favor the approach Cocoon takes to "modules". Cocoon is
configured to use one sitemap (config file), but that sitemap can mount
or include other sitemaps through the "mount" element. See
http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html#Mounting+sitemaps
Using wildcard
Martin Cooper wrote:
On Fri, 17 Dec 2004 12:13:21 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
Personally, I favor the approach Cocoon takes to "modules". Cocoon is
configured to use one sitemap (config file), but that sitemap can mount
or include other sitemaps through the
As you may have noticed, I've completed the merge of struts-chain with
Struts core (see the commit message for details). I would like to add
this is meant as a step forward, not as my ultimate vision for how
things should be, meaning if someone doesn't like a configuration
property name or pro
what
version is this anticipated to happen by? Finally, what is the branch
being used for right now?
TIA to anyone who can help clear this up for me.
sean
On Mon, 20 Dec 2004 23:30:31 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
As you may have noticed, I've completed the merge of struts-chain
You raise a good point. Unfortunately, only one parameter can be passed
through ActionMapping. DispatchChainAction really needs an
"allowedCommands" parameter to specify what commands would be allowed.
Perhaps we could use the new set/getProperty methods available in
ActionConfig where allowe
My basic assumption in approaching taglibs extraction into its own
subproject is it can reference Struts classes, but Struts classes
shouldn't reference it.
If that is correct, here are the changes I see happening to extract taglibs:
1. Move o.a.s.taglib out into its own subproject src tree
2. Remo
o this much but it would seem better to have a
completely separate tiles sub-project that struts core would use. Don't
JSF and Spring currently use tiles and have to include struts.jar when
all they really want is tiles?
-Original Message-
From: Don Brown [mailto:[EMAIL PROTECTED]
I'd like to request the following Bugzilla components be added:
- bsf
- sandbox
If I do this myself, please point me in the right direction. Thanks.
Don
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
Hal <[EMAIL PROTECTED]> wrote:
Haven't look into this much but it would seem better to have a
completely separate tiles sub-project that struts core would use. Don't
JSF and Spring currently use tiles and have to include struts.jar when
all they really want is tiles?
-Original
cated long enough, I could remove that and make things a lot
easier. I have yet to migrate all the tests, but that should be
straightforward.
Don
Craig McClanahan wrote:
On Tue, 21 Dec 2004 20:45:03 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
I agree as well. This lets us follow a consiste
.
Don
Joe Germuska wrote:
At 10:24 PM -0800 12/21/04, Don Brown wrote:
FWIW, so far, I extracted tiles and taglib into their own projects,
and got both core and taglib compiling (haven't tried tiles yet). It
took the steps I described earlier as well as moving some methods from
TagUtils back
ats on all the great work happening w/Struts right now.
i'm looking forward to when i've got a chance to play around with some
of these things.
Nathan Bubna
On Tue, 21 Dec 2004 18:29:43 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
It has been discussed, I believe, to separate Ti
d
attributes in the config? This would allow the util implementation to
not only be module scoped but request scoped if desired since the user
can have complete control over the chains.
Don
Joe Germuska wrote:
At 12:33 PM -0800 12/22/04, Don Brown wrote:
What about having a UtilityFactory
I'd like to see whats in Utils
become smaller and more tightly focused as small fragments of common code.
Niall
- Original Message -
From: "Don Brown" <[EMAIL PROTECTED]>
To: "Joe Germuska" <[EMAIL PROTECTED]>
Cc: "Struts Developers List"
Pardon the ignorance, but as I understand it, the struts-faces
integration library allows Struts components to be executed within the
JSF framework. JSF handles the request, then using special adapters,
actions are executed when desired.
If that is correct, would it be possible to implement JS
Craig McClanahan wrote:
On Thu, 23 Dec 2004 12:31:19 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
If that is correct, would it be possible to implement JSF within Struts
chain? Could a JSF implementation be decomposed into chain commands,
and therefore allow the user to mix and match?
You&
I've made further progress in extracting tiles and taglibs, and have run
into several issues I'd like to get some feedback on.
1. Tiles depends on TagUtils in taglibs. Tiles' version of TagUtils has
a link to taglib's TagUtils.getScope(). I could copy this method over
(it is a whole 5 lines),
Martin Cooper wrote:
On Fri, 24 Dec 2004 12:22:33 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
I've made further progress in extracting tiles and taglibs, and have run
into several issues I'd like to get some feedback on.
1. Tiles depends on TagUtils in taglibs. Tiles' vers
;t want to have to drag Struts around to do that.
So, I'm not sure what to do with my code. Do my goals for a standalone
Tiles align with the goals for the Tiles subproject within Struts?
david
Le Dec 24, 2004, à 3:30 PM, Martin Cooper a écrit :
On Fri, 24 Dec 2004 12:22:33 -0800, Don Bro
Martin Cooper wrote:
The new build system will consist of a few shared build files, and a
per-subproject build.xml file. This leads to the obvious question of
where the shared build files should live. There are basically two
options, as I see it:
1) In a 'build' subproject. This is the cleaner opti
t I'll have some cycles this coming week, which I was going
to spend on the build. So if you'd like some help with the
restructuring you're working on, let me know.
--
Martin Cooper
On Fri, 24 Dec 2004 12:22:33 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
I've made further pro
to do that.
david
And yes... Merry Christmas ;-)
Matthias
-Original Message-
From: David Geary [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 25, 2004 6:39 PM
To: Struts Developers List
Subject: Re: Taglibs and Tiles Extraction Issues
Merry Christmas, btw!
Le Dec 25, 2004, à 1:35 AM, D
Hmm...I can see your point, but I'd hate to have identical code in two
places to maintain. If there is enough community interest, I suppose we
could pull it out and create a release that won't be supported.
Don
Joe Germuska wrote:
At 7:34 AM + 12/21/04, [EMAIL PROTECTED] wrote:
* removed u
Martin Cooper wrote:
I just made a giant commit to the EL taglibs to bring them into
alignment with the non-EL tags. Now these changes need to be ported to
the 1.2.x branch, since the omission of these changes was, in part, the
reason for classifying 1.2.6 as Beta rather than GA, and we'll want
Ted Husted wrote:
I'm fine with (1).
As to things like Struts TestCase, if we decide to adopt it, then I'd suggest
that it be part of the Core itself.
Once you start using something like this, it becomes integral to development. The benefit of bringing in Struts TestCase, rather than just snaggi
The big argument, IMO, for bugzilla is Jakarta Commons uses it and it
makes it easy to reassign bugs that users mark against Struts to the
appropriate commons project.
Don
Sean Schofield wrote:
I would agree that the recent improvements in Bugzilla were definitely
a step in the right direction.
I don't mind sticking ActionContext everywhere as it is better than
having the code rely directly on the servlet api, but since we are
talking about modifying Action, why not get rid of this "must extend
Action" stuff and make Action an interface? IMO, Struts core should
depend on this new int
#x27;t think of
anything else that fits in with our current naming scheme, yet clearly
designates something as an interface.
Don
Dakota Jack wrote:
On Sun, 13 Feb 2005 14:05:11 -0800, Don Brown
I don't mind sticking ActionContext everywhere as it is better than
having the code rely direc
You make some good points, so I'll add my 2c:
1. The chain logic should be separate from the application logic, which
could, however, use common-chain. I'm fine with using a chain command
to replace Action, as long as it can be made clear the line between the
two processes. One defines how al
Joe Germuska wrote:
Psychologically, I would not deprecate the good old execute(1,2,3,4)
yet. Else Struts 1.3 will make all the millions of existing Struts
apps look old (which is the same as "bad" in the era of Nip/Tuck). "If
people want to code the old way, let them" (quote of my lead
develo
Joe Germuska wrote:
FWIW, I think Frank's idea of supporting POJO's as actions is the
best.The JSF model of "action" is, IMO, the way to go:
1. It is a POJO that doesn't have to extend or implement anything
2. It can have properties for simple pages that don't need separate
forms
3. It ca
Frank W. Zammetti wrote:
On Mon, February 14, 2005 12:27 pm, Don Brown said:
As for 2), users can use normal actionforms, _or_ simply define setters
on their POJO action class. In the latter case, Struts, behind the
scenes, could create a LazyDynaActionForm, and use it to run through
validation
Joe Germuska wrote:
Don wrote:
Adding to 3), it would be interesting to add "dialog" scope, something
Shale is working on for a scope that is for a logic process where
multiple instances might exist in a single session (think browser
cloning where two of the user's browsers are going through the
we gain consensus can we begin to address 2, and at this
stage, I think we still have a ways to go. What we can agree on,
however, is whatever solution and subsequent implementation we choose,
it will have to be 100% backwards-compatible with Struts 1.2.
Don
Joe Germuska wrote:
At 10:52 AM -0800
reduce the size of the
element names, since we don't have to make them unique.
If we did this, and the code detected an old DTD-based config, we just
apply an XSL transform and we have 100% backwards compatibility.
Don
Frank W. Zammetti wrote:
On Mon, February 14, 2005 2:28 pm, Don Brown
argue for wildcards in the action-beans to help group them. :)
Don
Joe Germuska wrote:
At 2:45 PM -0500 2/14/05, Frank W. Zammetti wrote:
On Mon, February 14, 2005 2:28 pm, Don Brown said:
- First level validation would be handled through
commons-validator as
we do now. Second level, the one
Joe Germuska wrote:
At 11:28 AM -0800 2/14/05, Don Brown wrote:
I think there are two questions we have to answer:
1. What is the best approach for request-specific logic code?
2. How can we integrate that into our current code base while
maintaining backward compatibility?
To me, we need to
Joe Germuska wrote:
My inclination at this point is to treat the most complicated questions
we're bumping up against as fertile ground for subprojects and
contrib-type code until we really see what people want and what works.
I don't think it is necessary to wrestle them all to the ground at
o
Of course, you and anyone else, are welcome to attack bugs in bugzilla
to speed us along to another release. What I personally would be
interested in is for you to explore your "vision" of how action
invocation should work, then rewrite a small app like the mail reader to
use it. I don't beli
he dev list?
What about those looking to contribute to the path the committers have chosen?
On Mon, 14 Feb 2005 15:18:10 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
Of course, you and anyone else, are welcome to attack bugs in bugzilla
to speed us along to another release. What I personally wou
27;t mind working on something that incorporates
FormDef's features to the Struts core, or even just contribute FormDef
to Struts directly.
On Mon, 14 Feb 2005 15:38:07 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
I think so. An idea with a working, and ideally deployed,
implementation is much
I see where you are coming from now Ted, and I agree a ViewContext would
be very useful. I had to write something similar for Struts BSF but to
put objects in the scripting scope.
To understand ViewContext, you need to realize:
data passed to view != request scope or even ActionContext
The reas
Ok, I give up - how do you build the Struts website? Last I remember, I
used ant which pulled the content from /docs but I can't seem to find
any site building task in build.xml. Are we now only using maven and
/xdocs?
Don
-
:
-Original Message-
From: Don Brown [mailto:[EMAIL PROTECTED]
This reminds me of this improvement Struts was going to make
a long time
ago, pre 1.1 days for stxx. stxx wanted to extend the Struts
config to
add support for multiple xslt transformations. The problem
was Struts
config was stuck
usted wrote:
On Tue, 15 Feb 2005 17:26:21 -0800, Don Brown wrote:
For implementation, I would favor adding a
ActionContext.getViewContext() method that returns a generic
Context map. The request processing chain could have a command or
chain of commands after the action executes to process the
View
karta Commons site.
Well, that gets us back into the Maven vs. Ant debate. I'd imagine we
don't want to have part of the build require Ant, and the other require
Maven. Are there any examples of this being done that use Ant?
Don
-Ted.
On Tue, 15 Feb 2005 17:55:53 -0800, Don Brown wrot
e we stand with this. There's been traffic on the list, but it's hard to keep up with the threads sometimes.
My own preference would be to use Maven, but, in the end, them that does the
work make the decisions.
-Ted.
On Wed, 16 Feb 2005 10:23:53 -0800, Don Brown wrote:
Ted Husted w
ld pick up our doc namespace elements and convert them into nice,
multi-format documentation. (I say custom namespace to allow us to
define docs in a limited taxonomy to improve the quality of our output
documentation.)
Don
Joe Germuska wrote:
At 10:16 AM -0800 2/16/05, Don Brown wrote:
T
visit the Struts Flow website at:
- http://struts.apache.org/flow/index.html
Don Brown
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks, and done. Let me know if there is anything I missed.
Don
Ted Husted wrote:
Never mind. I ran svnpasswd on the new machine, and now everything works :)
So, Don, you can make the changes, use core/build-site.xml to rebuild the site, and scp it up to /www/struts.apache.org.
-T.
On Thu, 17
t the risk of causing people to run around in little circles [ ;-) ],
can you tell me what Faces is? Is that MyFaces? How does Faces
differ from Shale? Thanks for any information. If the question
upsets anyone, my apologies.
Jack
On Thu, 17 Feb 2005 14:03:32 -0800, Don Brown <[EMAIL PROTECTED
t the risk of causing people to run around in little circles [ ;-) ],
can you tell me what Faces is? Is that MyFaces? How does Faces
differ from Shale? Thanks for any information. If the question
upsets anyone, my apologies.
Jack
On Thu, 17 Feb 2005 14:03:32 -0800, Don Brown <[EMAIL PROTECTED
And then there I go replying twice... :)
Don
Don Brown wrote:
The question is fine, but please don't reply to all the Struts lists.
Struts Faces is an integration library to allow Struts applications to
use the JSF taglibs. Apache Shale is a completely new framework that
builds on JSF and s
n
On Wed, 16 Feb 2005 08:10:04 -0800, Shey Rab Pawo
<[EMAIL PROTECTED]> wrote:
> On Sun, 13 Feb 2005 23:09:07 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
>
> See some thoughts and an implicit question within:
>
> > You make some good points, so I'll add my 2c:
&g
jects and I'd perfer to pass as little in the
context as possible.
Don
On Fri, 18 Feb 2005 11:35:20 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 9:04 AM -0800 2/18/05, Don Brown wrote:
> >You are correct, but in my opinion, these user commands that are
> >placed
tion 1 will really start to be
inadequate. Solution 2 feels like a hack, and solution 3 (executable
XML) has been shown a bad idea through Jelly.
I wonder what a merging of commons-chain and a scripting language like
beanshell would look like...
Don
Joe Germuska wrote:
At 10:00 AM -0800 2/18/05
]> wrote:
On Fri, 18 Feb 2005 09:04:32 -0800, Don Brown wrote:
There is a middle ground which I have been playing with on and off
frequently called "interceptors". In WebWork2, you can define
action interceptors that intercept certain actions, defined at a
per-action level. With Str
Martin Cooper wrote:
OK, I've created a build subproject, with trunk / tags / branches,
added it to 'current', and also added it to the following subprojects:
apps, bsf, core, el, faces, taglib, tiles. I have *not* added it to:
flow, sandbox, shale. Certainly shale uses a separate build system,
bu
I was looking at updating the Blank application and had a few questions:
1. Can I get rid of the data source stuff including the jdbc
extensions? Hasn't data sources been deprecated for quite a while now?
2. Any way we could ship with servlet.jar? It would be nice if this
could be completely
1 - 100 of 1641 matches
Mail list logo
