I agree here. I like having the safety of knowing that if we decide to re-architect
the presentation layer of our app (and we're looking at re-doing some of it with
Thinlets), then there could be a framework there to let us do that...
> -Original Message-
> From: Patrick Lightbody [mailt
I've added Joe Walnes' Component stuff and modified it to fit in the
Interceptor framework. It's really cool. I recommend that you check out the
sources and run the "example-war" target. As you can see, each time you
reload, the counter will increment. The cool thing is that if you look at
the cod
Happy new year everyone! I have a simple question about the tag
and performance using WW 1.2.1.
I have this list of countries that contains 245 entries. When I execute the following
fragment, it takes about 15 seconds to execute the iterator loop by itself. Any of
you WW gurus have some poi
Making unnecessary changes, IMHO, is definitely 'making it unpleasant'.
While I see that backward compatibility is too hard to keep (or so I'm
told) given all that people want xwork to be, I really dislike the
approach of change for changes sake. I deliberately avoided the very
early versions o
I know, it is possible to do this, but it's a bit more complicated, if only
because the user's (developers, whatever) don't actually _see_ the backing
map without opening up some stack method that provides access to the
ThreadLocal. If we pass the context around, all that happens is that
execute()
No one is going to make it unpleasant... you can be sure of that. It'll be
easier and more pleasant for everything. If you look at the CVS, I think
you'll agree. Today I'm going to put in an Interceptor that reads a
components.xml file, which contains a list of "components", and pulls three
things
Patrick Lightbody wrote:
ThreadLocal implies that you always have a single thread throughout the
lifecycle of the action (prepare, execute, print results). This is true for
a servlet container (single thread/request), but not so in other areas.
No, it doesn't imply that. If the execution chain i
boxed wrote:
It could be possible to add a flag for whether includes are mandatory or
not.
Seems like this is exactly what interceptors are for. You don't want to have
actions accessible directly from a url? Then add the interceptor that
prevents it.
Good point. That would work.
/Rickard
-
On Sat, Jan 11, 2003 at 08:11:26AM -0800, Patrick Lightbody wrote:
> ThreadLocal implies that you always have a single thread throughout the
> lifecycle of the action (prepare, execute, print results). This is true for
> a servlet container (single thread/request), but not so in other areas.
Can y
ThreadLocal implies that you always have a single thread throughout the
lifecycle of the action (prepare, execute, print results). This is true for
a servlet container (single thread/request), but not so in other areas.
If you look at the code, the context Map is being passed around. I don't
reall
I would highly recommend against going down this path. Otherwise, just focus
on WebWork 1.4. Plus, even if all our actions are used for the web, remember
that by making the core framework non-web-based, you also make testing much
easier as well.
-Pat
- Original Message -
From: "matt baldr
On Sat, Jan 11, 2003 at 09:29:33AM +0100, Rickard Öberg wrote:
> Peter Kelley wrote:
> >The other thing we might want to address is
> >whether or not XWork will be somewhat seperated at the core from the
> >web.
>
> This is a very difficult question. Separating it from the javax.servlet
> API sho
> A little poll:
As long as you are aware that any result from this poll is basically
meaningless I'm fine with this. It was pretty obvious last time this type of
thing was asked on the mailing list (URLTag) and it was acted on the result,
that the response that was given was grossly misleading. B
> It could be possible to add a flag for whether includes are mandatory or
> not.
Seems like this is exactly what interceptors are for. You don't want to have
actions accessible directly from a url? Then add the interceptor that
prevents it.
Anders Hovmöller
[EMAIL PROTECTED] http://boxed.killing
+1
- Original Message -
From: "Hani Suleiman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 11, 2003 6:29 AM
Subject: Re: [OS-webwork] XWork: core concepts
On Saturday, January 11, 2003, at 03:29 AM, Rickard Öberg wrote:
> This is a very difficult question. Separa
On Sat, 11 Jan 2003, [ISO-8859-1] Rickard Öberg wrote:
> Hani Suleiman wrote:
> > I strongly suspect that swing/non web usage makes up 1% or less of all
> > the users. Lets not make this unpleasant for the silent majority just to
> > win a marketing line or two or some coolness points by saying 'w
Hani Suleiman wrote:
I don't use any of those and am quite unlikely to eve ruse them. Reason:
I use app clients. webwork/xwork to me is ALL about being web only, and
its role is to handle view related stuff and marshall things for the
backend. EJBs do all the actual 'meat'. Appclients for me pr
On Saturday, January 11, 2003, at 03:29 AM, Rickard Öberg wrote:
This is a very difficult question. Separating it from the
javax.servlet API should be possible, but overall I have the feeling
that trying to make a *too* generic solution might be crippling.
A little poll:
*) How many have acti
Err, how is ThreadLocal servlet related? How would any of the context
stuff work without it?
On Saturday, January 11, 2003, at 03:56 AM, Patrick Lightbody wrote:
In effort to ditch the servlet paradigm, any thoughts on changing
ActionContext from being a ThreadLocal to just a normal Map? I've go
Patrick Lightbody wrote:
In effort to ditch the servlet paradigm, any thoughts on changing
ActionContext from being a ThreadLocal to just a normal Map?
Why do you want to get rid of ThreadLocal's? I think they're great, and
I'm having a hard time seeing how context is going to be passed around
A summary of the changes (read below for more):
* Removed ActionContext ThreadLocal in favor of a simple context Map
* Modified View, Action, and InterceptorChain interfaces/objects to have
access to the context Map
* Removed ActionFactory entirely in favor of interceptors
* Removed GenericDispatch
I'm looking into using Xworks mostly for actions with reuse of actions in all three
settings. Main use: Swing/SWT application; secondly, webservices and web application.
I'd be interested to see how the same action could be reused, with "just switching" of
dispatcher/interceptor necessary for in
I use (as does Jira) the same action served by both ServletDispatcher and
also WebWorkExecutor (part of OSWorkflow).
-Pat
- Original Message -
From: "Rickard Öberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 11, 2003 12:29 AM
Subject: Re: [OS-webwork] XWork: core
In effort to ditch the servlet paradigm, any thoughts on changing
ActionContext from being a ThreadLocal to just a normal Map? I've got some
code I can commit to CVS if you'd like to see how it would work.
-Pat
---
This SF.NET email is sponso
Peter Kelley wrote:
Good to have you back
I'm not back. I'm trying to see whether it's any point in me restarting
the XWork.
Are views a core concept ?
Tricky one. Yes, I guess they should be, somehow.
The other thing we might want to address is
whether or not XWork will be somewhat sepera
Philipp Meier wrote:
These are the core concepts that I can think of. Now, for my own
portlet-ish needs (which I hope will be more common for others too in
the future) the following applies:
* Actions and Components, and their resulting views, are ALWAYS called
through a servlet include. This m
26 matches
Mail list logo
