For patches to existing classes, we do operate on the premise that
there's an implicit grant, but when people start donating entire
classes, we like to have an explicit licensing agreement on file.
-Ted.
On 6/5/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote:
This looks weird, because as far as
This looks weird, because as far as I knew contributions submitted
through JIRA are already granting the copyright if not otherwise
expressed.
./alex
--
.w( the_mindstorm )p.
On 6/5/06, Ted Husted <[EMAIL PROTECTED]> wrote:
Since this donation includes standalone classes, we should ask Frank
t
Thanks Ted, I just faxed it over a minute ago... I just hope whoever looks
at it can read my handwriting, I have *seriously* atrocious penmanship!
It still needs to be sent in, correct?
Frank
On Mon, June 5, 2006 1:20 pm, Ted Husted wrote:
> Since this donation includes standalone classes, we s
Since this donation includes standalone classes, we should ask Frank
to file a CLA to cover this donation and any others.
* http://www.apache.org/licenses/icla.txt
I don't think we need to wait for it to go on file before accepting
the donation, but Frank should confirm that he is willing and ab
Hi Ian,
Your very welcome! It was fun working on it, learned quite a bit about WW
in the process... I opened a JIRA ticket that includes everything:
http://issues.apache.org/struts/browse/WW-1330
It has a link to a complete webapp demonstrating it (too big to attach to
the ticket I thought), bu
Frank -
Thanks again for all the work you've done on this front! Email the code
to me at [EMAIL PROTECTED] I'll take a look over it and commit it to the
saf project. If there are some interesting classes, you might want to
add them to the JIRA issuse for discussion
/Ian
Frank W. Zammett
FYI, for anyone that's interested and been following this discussion, I
finally got this all working, just need a few hours tomorrow night to do
some final polishing and documentation (not that it'll be perfect out of
the gate anyway, but I'd like to get as close as possible).
In short, there
Argh... just so no one thinks I forgot about this... I've had to work
from home all this week for various unforeseen reasons, and of course as
a pessimist like myself would expect, the mostly working code got lost
since this weekend. Thought there was a copy on my thumb drive, but of
course no
>
> Ted and Jason, I did see your messages about
> AroundInterceptor and
> Result correspondingly... right now, in the interest
> of simply getting
> it working, I'm just doing a simple AroundInterceptor
> using before() and
> after(), one interceptor for XML and one for JSON
> (although as I j
Thanks guys... quick update... I took yesterday off, so I'm not quite as
far as I would have liked :) It *is* memorial day weekend after all!
However, I did on Friday get reasonably far... at this moment, I have
XML input working for simple (i.e., non-collection) Action fields, as
well as out
The AroundInterceptor is an abstraction (that we've recently discussed
deprecating).
The cannonical idiom is to to call {{invocaton.invoke();}} to separate
any "before" code from any "after" code. The invoke method let any
other Interceptors and the Action fire.
The simplest example might from
On 5/25/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
> > Likewise, isn't JSON content supposed to be sent with
"text/javascript"?
actually, no, "application/json"
"text/*" types are meant to be things that are more human readable,
despite the historic reality of "text/javascript"
http://www.i
>
> It's been talked about here, but I don't know how
> much interest there
> might be... At this moment I'm grabbing the code I
> started and intend to
> finish it this weekend...
>
> My plan is to create 4 interceptors. Two for input
> and two for output,
> one each for XML and one each for JS
> Likewise, isn't JSON content supposed to be sent with "text/javascript"?
actually, no, "application/json"
"text/*" types are meant to be things that are more human readable,
despite the historic reality of "text/javascript"
http://www.ietf.org/internet-drafts/draft-crockford-jsonorg-json-
On Thu, May 25, 2006 2:30 pm, Frank W. Zammetti wrote:
> My plan is to create 4 interceptors. Two for input and two for output,
> one each for XML and one each for JSON.
See, I learned something already... I thought there was a difference
between Interceptors that fire before and after an Action,
On Thu, May 25, 2006 2:47 pm, Craig McClanahan wrote:
> I would expect a well-behaved client to set the content type on the
> incoming
> request to "text/xml" for XML content, so you should be able to check
> that.
Yes, I think that's a reasonable assumption (something, I'm ashamed to
say, my Ajax
On 5/25/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
On Thu, May 25, 2006 2:12 pm, Jason Carreira wrote:
> I'm still waiting to see how this plays out... I've been a big proponent
> of Dojo and built several Dojo widgets, but I understand that it can be
> tricky and not as easy to use as we'
On Thu, May 25, 2006 2:12 pm, Jason Carreira wrote:
> I'm still waiting to see how this plays out... I've been a big proponent
> of Dojo and built several Dojo widgets, but I understand that it can be
> tricky and not as easy to use as we'd all like. I think there'll be room
> for different strateg
>
> No, I definitely would love to see ajax support...I
> just think it needs
> to be done right. Integrating DWR looks like it
> might get a bit messy.
> Taking ideas from DWR, maybe even some of the code
> and/or the js libs,
> and building the support directly into SAF2 would be
> a better
Brian Dittmer wrote:
Ian Roughley wrote:
So, you are saying that your preference would be to include no ajax
integration and leave the framework and let users integrate this as
required - either directly in the HTML or by creating custom themes?
/Ian
No, I definitely would love to see ajax
On 5/24/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
but if you want to model best practices, then you have to ask "why
would you be intent on calling Actions"? I'm not trying to build
walls so that people can't just get-the-job-done, but I do know from
experience that people tend to overload Act
Ian Roughley wrote:
So, you are saying that your preference would be to include no ajax
integration and leave the framework and let users integrate this as
required - either directly in the HTML or by creating custom themes?
/Ian
No, I definitely would love to see ajax support...I just think
So, you are saying that your preference would be to include no ajax
integration and leave the framework and let users integrate this as
required - either directly in the HTML or by creating custom themes?
/Ian
--
From Down & Around, Inc.
Innovative IT Solutions
Software Architecture * Design
I'm going to take a moment to chime in here as I've been watching this
thread develop. I'm going to come out in the open and say I've never used
DWR or even looked at it's documentation. When I've used ajax
functionality in the past we've simply made the XmlHttpRequest hit an
action that in turn
> > but if you want to model best practices, then you
> have to ask "why
> > would you be intent on calling Actions"? I'm not
> trying to build
> > walls so that people can't just get-the-job-done,
> but I do know from
> > experience that people tend to overload Actions
> with too much
> > busines
On Wed, May 24, 2006 12:09 pm, Joe Germuska wrote:
> At 11:55 AM -0400 5/24/06, Frank W. Zammetti wrote:
>>On Wed, May 24, 2006 11:12 am, Joe Germuska wrote:
>> > Forgive me if this has been covered elsewhere, but I'm still confused
>>> about why someone would want to "integrate" DWR with Struts?
On 5/24/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
At 11:55 AM -0400 5/24/06, Frank W. Zammetti wrote:
>On Wed, May 24, 2006 11:12 am, Joe Germuska wrote:
> > Forgive me if this has been covered elsewhere, but I'm still confused
>> about why someone would want to "integrate" DWR with Struts?
On 5/24/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
On Wed, May 24, 2006 11:22 am, Alexandru Popescu wrote:
> In my case I couldn't see a real benefit of having 2 different ways to
> "call" server-side functionality. For me it makes a lot of sense, that
> everything exposed by the server mus
At 11:55 AM -0400 5/24/06, Frank W. Zammetti wrote:
On Wed, May 24, 2006 11:12 am, Joe Germuska wrote:
> Forgive me if this has been covered elsewhere, but I'm still confused
about why someone would want to "integrate" DWR with Struts? I've
only used it a bit, but in each case, I didn't real
On Wed, May 24, 2006 11:22 am, Alexandru Popescu wrote:
> In my case I couldn't see a real benefit of having 2 different ways to
> "call" server-side functionality. For me it makes a lot of sense, that
> everything exposed by the server must be an action. This allows me to
> re-use almost everythin
On Wed, May 24, 2006 11:12 am, Joe Germuska wrote:
> At 10:46 AM -0400 5/24/06, Frank W. Zammetti wrote:
>>I haven't seen your work, so I can't talk intelligently about it... I
>>would agree though that if DWR is going to make HTTP calls to execute
>>Actions (a suggestion I might add that I made ab
In my case I couldn't see a real benefit of having 2 different ways to
"call" server-side functionality. For me it makes a lot of sense, that
everything exposed by the server must be an action. This allows me to
re-use almost everything and maybe later on to redesign my site by
mixing AJAX with no
At 10:46 AM -0400 5/24/06, Frank W. Zammetti wrote:
I haven't seen your work, so I can't talk intelligently about it... I
would agree though that if DWR is going to make HTTP calls to execute
Actions (a suggestion I might add that I made about two months ago to Joe
with regard to how to better in
33 matches
Mail list logo
