Wendy Smoak wrote:
On 1/10/06, Ted Husted <[EMAIL PROTECTED]> wrote:
In the interest of effective filtering, we should agree on a standard
subject tag for the Struts Action framework. For the Struts Shale
framework, we've been using [Shale]. So, for the other, should we use
* [SAF 2.x]
or
Here's my (advisory-only) +1. As someone who's been working on a
project (Beehive) that's always had a dependency on Struts, I think this
would really help increase the transparency of the release process.
Rich
Patrick Lightbody wrote:
>I don't think I get to vote just yet, but I'd be a big +1.
about this project and think it will be
>>>beneficial to users and developers alike. The Struts Classic code base
>>>is showing its age, but speaking as a developer who maintains old Struts
>>>apps, few people have the time and budget to rewrite them from scratch
>>>
; Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: [EMAIL PROTECTED]
> Skype: callto://jmitchtx
>
>
>
>
>
> On Sep 14, 2
Don,
Thanks for getting the patch from
http://issues.apache.org/bugzilla/show_bug.cgi?id=36607 in so quickly.
Here are some notes about this, for general consumption:
- This checkin provides build-time support for generation of the XDoclet
config files using either annotations (apt) or tags
/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: [EMAIL PROTECTED]
> Skype: callto://jmitchtx
>
>
>
>
>
> On Sep 13, 2005, at 2:23 AM, Rich Feit wrote:
>
>> Sorry about that -- you can take cppdoc.com off of the list if your
>> home
>>
Sorry about that -- you can take cppdoc.com off of the list if your home
dir is a reliable spot. cppdoc.com isn't reliable lately. :S
[EMAIL PROTECTED] wrote:
>Author: jmitchell
>Date: Mon Sep 12 20:57:45 2005
>New Revision: 280484
>
>URL: http://svn.apache.org/viewcvs?rev=280484&view=rev
>Log:
itchtx
MSN: [EMAIL PROTECTED]
Skype: callto://jmitchtx
On Sep 5, 2005, at 5:27 PM, Rich Feit wrote:
Sorry for the delay on this thread... just catching up now.
Currently the minimum in the non-Java5 code is 1.4, although we
never discussed it. I think supporting 1.3 would be really hard,
b
are Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: [EMAIL PROTECTED]
Skype: callto://jmitchtx
On Sep 2, 2005, at 1:19 AM, Rich Feit wrote:
Sounds good from my point of
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: [EMAIL PROTECTED]
Skype: callto://jmitchtx
On Sep 2, 2005, at 12:53 AM, Rich Feit wrote:
Sorry, I should have been clearer. I was thinking specifically of
any build-time support we provide, like generating files based on
annotations/tags
itchtx
MSN: [EMAIL PROTECTED]
Skype: callto://jmitchtx
On Sep 2, 2005, at 12:57 AM, Rich Feit wrote:
First, I just want to mention that I've never been involved in a
project where anyone's given so much thought/attention to the build
from the ground up. Thank you -- it's a p
CTED]
Skype: callto://jmitchtx
On Sep 1, 2005, at 4:32 AM, Rich Feit wrote:
Hi all,
I've added a patch (http://issues.apache.org/bugzilla/show_bug.cgi?
id=36454) for a sample that demonstrates using JSF as the view layer
for a Ti app. It's a straight port of the Beehive/JSF s
techservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: [EMAIL PROTECTED]
Skype: callto://jmitchtx
On Sep 2, 2005, at 12:41 AM, Rich Feit wrote:
OK, I just tried this. But the main thing I'm wondering about here
is the project model for our users (rather than for us). To
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: [EMAIL PROTECTED]
Skype: callto://jmitchtx
On Sep 1, 2005, at 3:20 PM, Rich Feit wrote:
That
callto://jmitchtx
On Sep 1, 2005, at 2:06 PM, Rich Feit wrote:
Ahh... 'maven jar-all war-all'. Nice. Thanks, James.
James Mitchell wrote:
A better option might be to run any of the '*-all' targets listed
here...
http://svn.apache.org/viewcvs.cgi/struts/sandbox
x27;maven jar jar:install' in jars/core and jars/java5
'maven war' in wars/samples
to build a war that you can deploy in a Tomcat container.
A big thanks to Rich Feit and James for the Page Flow stuff and
Maven build respectively.
Don
-
Hi all,
I've added a patch
(http://issues.apache.org/bugzilla/show_bug.cgi?id=36454) for a sample
that demonstrates using JSF as the view layer for a Ti app. It's a
straight port of the Beehive/JSF sample. It doesn't necessarily show
off JSF (or JSF best practices), but it does demonstrate
Craig McClanahan wrote:
On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote:
Using JSF is actually what convinced me that having the context on
ThreadLocal is a great thing. It really cleans up the APIs. (Nice job
BTW :) ). Our ActionContext will give us something similar... but I do
Don Brown wrote:
Craig McClanahan wrote:
On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote:
I actually agree that a single bean is better than a lot of separate
values under various keys. In Beehive we put most of our request-scoped
values onto a request wrapper -- this turned out t
Craig McClanahan wrote:
On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote:
I actually agree that a single bean is better than a lot of separate
values under various keys. In Beehive we put most of our request-scoped
values onto a request wrapper -- this turned out to have better
perfo
in Struts is one of its weakest points,
making it hard to test and hard to refactor, so I'd hate to see Ti
make the same mistakes...
Joe
At 9:00 PM -0600 8/30/05, Rich Feit wrote:
It's transitional -- not necessarily for back-compat. I should have
commented it as such. In Bee
It's transitional -- not necessarily for back-compat. I should have
commented it as such. In Beehive, we were using these four constants
that Struts defined for storing errors, exceptions, locale, etc. I
think it's something we need to work out -- do we want to keep storing
these things in a
jmitchtx
Yahoo: jmitchtx
MSN: [EMAIL PROTECTED]
Skype: callto://jmitchtx
On Aug 30, 2005, at 1:00 AM, Martin Cooper wrote:
Works for me too.
--
Martin Cooper
On 8/29/05, Rich Feit <[EMAIL PROTECTED]> wrote:
Sounds great to me, actually. It's cleaner in general.
R
ed to do? Is this supposed
to be the beginnings of a mailreader?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: [EMAIL PROTECTED]
Skype: callto://jm
Sounds great to me, actually. It's cleaner in general.
Rich
Don Brown wrote:
Doesn't matter to me as long as it works :)
Don
James Mitchell wrote:
Ok, I've hit a bit of a snag...
In Maven-utopia, the project layout would support multiple JAR and
WAR artifacts by nesting then 1 level de
Currently, you can cd into core and run 'maven jar' using Java 1.4.
Building the entire project (including the 'java5' module) requires Java
5. Does that sound reasonable? The two modules do currently build to
separate jars.
Currently the 'samples' module (webapp) is written against the
an
I agree -- Ti can succeed in offering good server-side rich application
support. There will be overlap and ironing out between this approach
and frameworks that try to define an entire application model on the
client, but I think there's a sweet spot to be hit here.
Also (to address an earlie
/ Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: [EMAIL PROTECTED]
Skype: callto://jmitchtx
On Aug 29, 2005, at 12:56 AM, Rich Feit wrote:
One other comment... there are actually two separate source
modules: 'core'
One other comment... there are actually two separate source modules:
'core' and 'java5' (the latter contains annotation definitions, and
targets java5 binary). Both need to be built. What I was doing to
build/run all this was:
cd core
maven jar jar:install
cd ../java5
maven jar j
Ted Husted wrote:
On 8/22/05, Rich Feit <[EMAIL PROTECTED]> wrote:
p.s. In some ways, JSF is a direct competitor to ASPX in ASP.NET, which
is still figuring out the whole navigational-controller thing. In the
rare event that I imagine myself to be on a "side", in a &quo
imagine myself to be on a "side", in a "battle", I
consider myself to be on the side that contains JSF+Struts+Shale,
looking across the field at ASP.NET. :) And even then, I'm only on
that side because I want the more community-driven ecosystem to prevail.
Ted Husted wrote:
forward to
getting this into Ti ASAP.
Don
Rich Feit wrote:
Quick correction: In both of the sample apps, you need to run 'ant
build' in WEB-INF/src. No maven yet.
Rich Feit wrote:
Hi all,
Attached is a patch that contains a first cut at Page Flow support
within Struts Ti (sandbo
Hmm... I'm just about to post a reply to that entry. Basically, I feel
that although JSF itself can be great view-tier technology, it isn't
really a full replacement for Struts. JSF+Shale *is* a replacement for
Struts, but I think that's a point which is often lost. An interesting
thing abou
Quick correction: In both of the sample apps, you need to run 'ant
build' in WEB-INF/src. No maven yet.
Rich Feit wrote:
Hi all,
Attached is a patch that contains a first cut at Page Flow support
within Struts Ti (sandbox). It's basically Beehive Page Flow, minus
Struts 1.x
Hi all,
Attached is a patch that contains a first cut at Page Flow support
within Struts Ti (sandbox). It's basically Beehive Page Flow, minus
Struts 1.x, minus Servlet, plus XWork, plus some refactoring. And minus
a bunch of functionality that I had to disable in the process.
There are three
I just want to clarify on the Beehive angle... it's a common
misperception that Beehive is all about controls, or all about web
services, or all about page flow. It contains all three fairly
independent pieces (the conceptual link is that all use annotations in
the programming model, and the code
36 matches
Mail list logo
