On 11/1/05, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:
Thanks Greg! A few questions...
+ The Tiles 1.1 Framework Project - Examples
The release plan has Struts Tiles as part of the 1.3.0 release, and I think
this should be changed to 1.3. I've already changed the version in the tld,
but didn'
Author: gvanmatre
Date: Tue Nov 1 20:07:26 2005
New Revision: 330187
URL: http://svn.apache.org/viewcvs?rev=330187&view=rev
Log:
Rearranged the processing of the new symbol replacement so that a symbol value
containing EL will be evaluated.
Modified:
struts/shale/trunk/clay-plugin/src/java
This sort of question belongs on the user list rather than the dev list.
See my reply there. Also, please don't post the same message to both
lists; pick the appropriate one and just post there:
http://struts.apache.org/mail.html
L.
sma3har wrote:
Hi,
I am getting this following error when
Yujun Liang wrote:
Laurie,
Thanks for all the replies.
Can you point me to a document describe how to change the default converter
used by Struts? I was not aware of that.
Struts uses the default converter supplied by BeanUtils directly, it
doesn't have its own instance.
By the way, what'
Please do not cross-post messages. I already mailed you earlier today,
informing you that dev@ is the wrong list for your questions. Please read
the mailing list guidelines here:
http://struts.apache.org/mail.html
--
Martin Cooper
On 11/1/05, sma3har <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> My dy
Hi,
My dynaaction form has an array of bean objects. I am
trying to iterate through the list and accept some
values in my jsp page. But when i submit my jsp page
it does not have these values.
Can anyone tell if i should write my hidden in a
different form. Please help me.
Sujji
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Struts Wiki" for change
notification.
The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/fdfdf
The comment on the change is:
Test page, removed
--
[snip]
> A larger scale demo app that really showed off Shale would be very useful as
> well. It wouldn't *have* to be MailReader 2.0 ... it could be something new
> (after all these years :-). Such an app would need to cover enough
> functionality areas to show off Dialogs and the application lev
On 11/1/05, Andy W Freeman <[EMAIL PROTECTED]> wrote:
>
> Craig,
>
> Do you know how well Shale and Facelets work together?
>
> https://facelets.dev.java.net/
>
> thanks,
> Andy
>
I did a couple quick experiments, and it seemed to be fine. The only
slightly tricky part is that Shale uses JSF 1.1,
Author: germuska
Date: Tue Nov 1 11:58:40 2005
New Revision: 330112
URL: http://svn.apache.org/viewcvs?rev=330112&view=rev
Log:
Provide support for specifying an alternative ActionContext implementation
class
in struts-config.xml rather than requiring subclassing of
ComposableRequestProcessor.
Craig,
Do you know how well Shale and Facelets work together?
https://facelets.dev.java.net/
thanks,
Andy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> On 11/1/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> (1) Is your team planning a new web application project over the next
> twelve months?
Yes, multiple actually.
> (1a) If so, what web application framework do you plan to use?
Struts 1.2.x (1.2.4 at the moment, trying to at least push to 1.2.
On 11/1/05, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> On 11/1/05, James Mitchell wrote (elsewhere):
> > I guess the big difference
> > (for me) now is that I actually have a paying gig doing JSF/Shale, so
> > there's more incentive for me.
>
> Which begs a query to the group:
>
> (1) Is your team p
On Tue, November 1, 2005 1:21 pm, Ted Husted said:
>> That still allows you to have true sub-projects like Struts Ti, Struts
>> I wasn't aware of the points you made about Validator Ted... are you
>> saying that the Commons Validator has been altered in such a way that it
>> can no longer be separa
Well, in a perfect world, Shale and TI they would depend on Core ;-) But
who wants to create dependencies for dependency sake?
You're correct, now of course we already have the struts-core
(requestprocessor) subproject living next to shale, without dependency.
So we don't really change much in t
On 11/1/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> The first is simply the question of what is the name of the project at
> large? Is it still Apache Struts? And then everything else falls
> underneath it?
Yes. It's unlikely that the project name would change, since, as
Martin points out,
On 11/1/05, Wolfgang Gehner <[EMAIL PROTECTED]> wrote:
> Is Shale part part of the six original subprojects, and thus part of
> Struts Original?
No, it is separate (but equal).
> I maintain that the new RequestProcessor and COR is not classic, but
> new. And that COR should be highlighted as suc
On 11/1/05, Wolfgang Gehner <[EMAIL PROTECTED]> wrote:
>
> [snip]
> Shale won't use it, and probably TI neither? Or is Shale the odd one
> out? If it is, I guess you could say Shale is weakening the stature of
> Struts.
FWIW, Shale's application controller uses exactly the same technology that
th
On Tue, November 1, 2005 12:36 pm, Martin Cooper said:
> At some point, we may need to distinguish more clearly between Struts, the
> ASF project, and Struts, the framework, and I think that's essentially
> what
> we're starting to see a need for in these threads. It's not really all
> that
> diffe
On 11/1/05, James Mitchell <[EMAIL PROTECTED]> wrote:
>
> I can't find my changes to the mailreader app that makes it
> compatible with mailreader-dao, so I'd have to start over, which I
> really don't mind doing, but what do you think about a Mailreader 2.0?
That may well be appropriate ... but
On 11/1/05, Wolfgang Gehner <[EMAIL PROTECTED]> wrote:
> I maintain that the new RequestProcessor and COR is not classic, but
> new. And that COR should be highlighted as such, new.
I wouldn't agree with this, if you look at Struts evolution
* In Struts 1.0 all the "request processing" was in
On 11/1/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>
> On Tue, November 1, 2005 11:13 am, Michael Jouravlev said:
> > Struts Core sounds like a kernel for all Struts subprojects, while
> > AFAIK Shale and Ti do not depend on it. So, in a way this name is
> > misleading. Not that I can suggest
So I guess Struts Core is not Core after all. If that's the case, too
bad for all the good work in the request processor.
Shale won't use it, and probably TI neither? Or is Shale the odd one
out? If it is, I guess you could say Shale is weakening the stature of
Struts.
I understand, but I se
Author: greddin
Date: Tue Nov 1 08:59:27 2005
New Revision: 330092
URL: http://svn.apache.org/viewcvs?rev=330092&view=rev
Log:
More documentation changes:
- Added structure for User's Guide
- Added structure for Examples
- Updated Installation.
Added:
struts/tiles/trunk/xdocs/examples.xml
On 11/1/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> (1) Is your team planning a new web application project over the next
> twelve months?
Yes.
> (1a) If so, what web application framework do you plan to use?
* Struts, since JSP taglibs are available to support multi-channel
applications tha
+1
Wolfgang Gehner wrote:
+1
Wolfgang Gehner
Ted Husted wrote:
On 11/1/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
I haven't been a fan of the naming convention being introduced, and
I've
said so in the past. But, as Ted points out in another post, no one,
including me, offered
1) yes, actually a large one is scheduled for januar and another large
one for august/september. No to mention up to 5 smaller apps.
1a) struts-core + tiles, no dynaforms, no chaining, no validators (we
already have all this + ajax on top usage-ready), so basically
actionsservlet +actions + tiles
On Tue, November 1, 2005 11:13 am, Michael Jouravlev said:
> Struts Core sounds like a kernel for all Struts subprojects, while
> AFAIK Shale and Ti do not depend on it. So, in a way this name is
> misleading. Not that I can suggest something better ;-)
I think that's a fair point, although I thin
On Tue, November 1, 2005 11:02 am, Ted Husted said:
> To summarize,
>
> * Instead of having a Struts Classic distribution, we could have a
> "struts-core-library" distribution instead, that could also include
> other Core compatiblity extensions, like Struts Flow and Struts
> Scripting. If we did,
1) In the process of doing one now, Struts 1.2.7.
2) Don't know enough about other frameworks, but for now would stay
away from component-based ones (JSF, Tapestry). Wicket and Stripes
look interesting, but they're pretty green.
As an aside, the rest of the team I'm on was just trained (formally)
On 11/1/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> * Instead of having a Struts Classic distribution, we could have a
> "struts-core-library" distribution instead, that could also include
> other Core compatiblity extensions, like Struts Flow and Struts
> Scripting. If we did, then "Struts Classic
+1
Wolfgang Gehner
Ted Husted wrote:
On 11/1/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
I haven't been a fan of the naming convention being introduced, and I've
said so in the past. But, as Ted points out in another post, no one,
including me, offered any better suggestions either,
On Nov 1, 2005, at 9:54 AM, Ted Husted wrote:
(1) Is your team planning a new web application project over the next
twelve months?
Yes.
(1a) If so, what web application framework do you plan to use?
Probably Shale. Although, I have not had very much time to figure
shale out yet. I can s
On 11/1/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> I haven't been a fan of the naming convention being introduced, and I've
> said so in the past. But, as Ted points out in another post, no one,
> including me, offered any better suggestions either, so it was just
> pointless whining. Let
Hi,
I am getting this following error when i try to submit
the form that iterates over arraylist of objects.
Please help me with this error.
Nov 01 09:45:55 2005: Servlet action: unable to
service request: BeanUtils.populate
Nov 01 09:45:55 2005: javax.servlet.ServletException:
BeanUtils.populate
On 11/1/05, James Mitchell wrote (elsewhere):
> I guess the big difference
> (for me) now is that I actually have a paying gig doing JSF/Shale, so
> there's more incentive for me.
Which begs a query to the group:
(1) Is your team planning a new web application project over the next
twelve months?
On 11/1/05, Wolfgang Gehner <[EMAIL PROTECTED]> wrote:
>
> I have a humble suggestion, as 1.3 release seems to be eminent.
>
> I've worked with 1.3 dev since January this year, on large projects,
> too, and I think that the new chains design is worth a lot more than a
> minor point release. We are
I haven't been a fan of the naming convention being introduced, and I've
said so in the past. But, as Ted points out in another post, no one,
including me, offered any better suggestions either, so it was just
pointless whining. Let me try and change to something more
constructive...
Why not tak
How about a MailReader 1.3 for now? :)
I think we should definately use MailReader as a small best practices
demonstration of Shale as well as Core.
Steve uploaded the CookBook to Apps, so we don't need to stretch the
example anymore. I believe we should write the MailReader the way we
write our
I can't find my changes to the mailreader app that makes it
compatible with mailreader-dao, so I'd have to start over, which I
really don't mind doing, but what do you think about a Mailreader 2.0?
What I mean is a rewrite of the same functionality into new code that
can demo some of the re
On 11/1/05, Wolfgang Gehner <[EMAIL PROTECTED]> wrote:
> So let me formally propose that Struts point releases as of 1.3
> including be called Struts CORE.
I think the point that people are missing is that Struts Classic is
not a product, it's a distribution of products. Struts Core is one
product
Ted,
Another trigger might be a revolutionary change to the feature set. If
we did everything that's already on the 1.3 to 1.5 roadmap, I could
see going to 2.x then.
To me chains.xml, decompose and adapt the request processor and ability
to use Commands instead of Actions is a revolution. G
We do discuss everything, right here, right now :)
Having a separate menu block for Frameworks and Extensions makes
sense, so I updated the site home page.
Once Struts Classic is available as a discrete entity, we might have
another for "Distributions", since that's what Struts Classic is, a
dist
Author: husted
Date: Tue Nov 1 04:16:41 2005
New Revision: 330039
URL: http://svn.apache.org/viewcvs?rev=330039&view=rev
Log:
Add separate sections for "framework" subprojects and "extension" subprojects.
Modified:
struts/site/trunk/xdocs/navigation.xml
Modified: struts/site/trunk/xdocs/nav
On 11/1/05, Wolfgang Gehner <[EMAIL PROTECTED]> wrote:
> To me, 1.3 should be called 2.0.
The thinking has been that so long as each release is backwardly
compatible with the last, then there is no reason to increment the
major version number.
A couple of things that might trigger incrementing th
Yup, the true beauty of chains architecture and chain.xml is that it's
soo easy to blend out stuff you don't need in a particular extension or
configuration (and swap in other stuff), so you don't give anything away
by having Core as Core "for everything".
Of course the Core code needs to be i
Hi Wolfgang,
Maybe you are right and Core should be Core, and
the rest should be Extensions.
But if I look at the wegsite...
http://struts.apache.org/
I see that Core is one of many Subprojects on the
same level such as Shales, Tiles, etc.
If I read the text, it says...
"Apache Struts is a hot
That's the thing, Ti, Shale are subprojects like Tiles, and should be
understood as such, which means keeping the naming of Struts CORE
strong. Here, the core has really evolved to a new version. And it's a
very strong core. Just comes to my mind that CORE could be read as
"Chain Of REsponsibil
As an "outsider" the marketing of Struts currently tells me that
there are many cells of people working on different editions
of Struts... Ti, Shale, Classic, etc.
Yes, I guess that is confusing, and yes, propably those groups
should come together to discuss if they have commons.
Do you think th
I have a humble suggestion, as 1.3 release seems to be eminent.
I've worked with 1.3 dev since January this year, on large projects,
too, and I think that the new chains design is worth a lot more than a
minor point release. We are getting GREAT bang from the new flexibility
this *major new fe
50 matches
Mail list logo
