ursday, January 02, 2003 2:36 AM
Subject: Re: [OS-webwork] Rethink
> Patrick Lightbody wrote:
> > Great! So we can expect a finished product by Friday? :)
>
> Friday? *yawn* :-)
>
> > Glad to have you on board with this. Of course, I'll be around to help
in
> > any way
Jason Carreira wrote:
Some goals I would hope for:
* declarative security friendly URLs and the ability to protect your
actions from being called.
See the "Action invocation" post. .action URL's should go away with that.
* multiple configuration files, to improve multi-user version control
co
> -Original Message-
> From: Rickard Öberg [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 02, 2003 5:37 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Rethink
>
>
> Patrick Lightbody wrote:
> > Great! So we can expect a finished product by
> -Original Message-
> From: Rickard Öberg [mailto:[EMAIL PROTECTED]]
> Here are some that I can think of:
> * Try to avoid .action URL's
> * Allow for multiple read-actions to be on the same page (HMVC)
> * Allow for multiple forms to be on the same page, and be developed
> independentl
Agree. I think there is obvious areas certain people can help.
-Matt
- Original Message -
From: "Mike Cannon-Brookes" <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]>
Sent: Thursday, January 02, 2003 7:30 AM
Subject: Re: [OS-webwork] Rethink
Yep - +1 from me, but I think Patrick should also have a major role in
contributing, he has done a lot of the initial Xwork thinking and I think
his knowledge of OGNL etc would be valuable.
-mike
On 2/1/03 9:06 PM, "Rickard Öberg" ([EMAIL PROTECTED]) penned the words:
> matt baldree wrote:
>> Pe
> Currently, there's no way to
> keep people from executing your actions without creating a separate J2EE
> declarative security entry for each action (and each alias, etc). This
> is, IMHO, a HUGE drawback.
...or just a servlet filter.
Anders Hovmöller
[EMAIL PROTECTED] http://boxed.killingar.ne
Patrick Lightbody wrote:
Great! So we can expect a finished product by Friday? :)
Friday? *yawn* :-)
Glad to have you on board with this. Of course, I'll be around to help in
any way possible -- just gimme a holler.
Will do. I'm afraid I'm gonna thrash around in the current sandbox code
qui
gt;
Sent: Thursday, January 02, 2003 2:06 AM
Subject: Re: [OS-webwork] Rethink
> matt baldree wrote:
> > Personally, I like these ideas. I think this design would lead people to
> > cleaner solutions. I think it is time to make some decisions. I think
> > Rickard shoul
matt baldree wrote:
Personally, I like these ideas. I think this design would lead people to
cleaner solutions. I think it is time to make some decisions. I think
Rickard should architect XWork. It would then be up to him to
assign/delegate work on different modules, etc. I'm not convinced the
cur
Chris Nokleberg wrote:
If the URL hierarchy reflects the structure of the application(*),
Which it IMHO shouldn't.
What else would it reflect? I'm not being surly, I really am curious.
Ok, what I meant was that it shouldn't reflect the implementation of the
application. Because implementati
On Wed, Jan 01, 2003 at 07:17:15PM +0100, Rickard Öberg wrote:
> Chris Nokleberg wrote:
> >If the URL hierarchy reflects the structure of the application(*),
>
> Which it IMHO shouldn't.
What else would it reflect? I'm not being surly, I really am curious.
> >I
> >think many cross-cutting aspec
Chris Nokleberg wrote:
If the URL hierarchy reflects the structure of the application(*),
Which it IMHO shouldn't.
I
think many cross-cutting aspects such as persistence and security will
be very cleanly expressed as URL patterns.
It may "kind of" work for those, but then there's the transac
On Wed, Jan 01, 2003 at 09:48:47AM -0800, Chris Nokleberg wrote:
> On Wed, Jan 01, 2003 at 12:36:38PM +0100, Rickard Öberg wrote:
> > Chris Nokleberg wrote:
> > >I think it would be more useful if instead of applying directly to
> > >actions, the filters/interceptors applied to paths (URLs). The pa
On Wed, Jan 01, 2003 at 12:36:38PM +0100, Rickard Öberg wrote:
> Chris Nokleberg wrote:
> >I think it would be more useful if instead of applying directly to
> >actions, the filters/interceptors applied to paths (URLs). The paths
> >could support wildcards, either Servlet-style or a more complete r
t, I want it to be GREAT.
-Matt
- Original Message -
From: "Rickard Öberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 01, 2003 5:51 AM
Subject: Re: [OS-webwork] Rethink
> Jason Carreira wrote:
> > Along this line, I've mention
Jason Carreira wrote:
Along this line, I've mentioned before that one of the top requirements
I've got for a framework, and we're hopefully going to be switching to a
new (better) framework in the next few months, is the ability to use
J2EE declarative security to secure paths. This means that the
Chris Nokleberg wrote:
On Tue, Dec 31, 2002 at 10:21:21AM +0100, Rickard Öberg wrote:
Patrick Lightbody wrote:
Yeah, doesn't yet, but the plan is to add that in soon. Tonight I'll make
the code quicker and then start incorporating Rickards ideas.
Well, since this is looking more and more lik
Along this line, I've mentioned before that one of the top requirements
I've got for a framework, and we're hopefully going to be switching to a
new (better) framework in the next few months, is the ability to use
J2EE declarative security to secure paths. This means that the way
actions are invoke
On Tue, Dec 31, 2002 at 10:21:21AM +0100, Rickard Öberg wrote:
> Patrick Lightbody wrote:
> >Yeah, doesn't yet, but the plan is to add that in soon. Tonight I'll make
> >the code quicker and then start incorporating Rickards ideas.
>
> Well, since this is looking more and more like a lightweight v
By all means, go for it!
- Original Message -
From: "Rickard Öberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 31, 2002 1:21 AM
Subject: Re: [OS-webwork] Rethink
> Patrick Lightbody wrote:
> > Yeah, doesn't yet, but the plan
* View code. The old taglib contained code that was to some extent
duplicated for the Velocity view. This needs to be refactored so that
views can share such implementations.
On this point. If you take a look at the code to Roller you'll see it's
author created a novel way to reuse Tags acro
Patrick Lightbody wrote:
Yeah, doesn't yet, but the plan is to add that in soon. Tonight I'll make
the code quicker and then start incorporating Rickards ideas.
Well, since this is looking more and more like a lightweight version of
my AOP framework I can do the interceptor/XML fixes myself, if
Patrick Lightbody wrote:
I can apply some real-world examples here:
I'm in a screen that is updating document metadata, and the form submits to
UpdateMetadata.action. But UpdateMetadata.action is actually an alias for a
complex chain:
ValidateMetadata -> BeginTx -> StoreMetadata -> CommitTx ->
S
TED]>
Sent: Monday, December 30, 2002 3:07 PM
Subject: Re: [OS-webwork] Rethink
> >>> My favourite usecase is the show-edit-update-show usecase. Which means
> >>> having the need to pass the primary key of the object updated to the
> >>> action show which
>>> My favourite usecase is the show-edit-update-show usecase. Which means
>>> having the need to pass the primary key of the object updated to the
>>> action show which is the view of the Update action. Views.proptiers
>>> whould look like that:
>>>
>>> Show.success=show.xslt
>>> Update.success=S
> Packaging I would define as the ability to create 'components'
consisting
> of
> WW actions, configuration for those actions and the views. With
Velocity
> (loaded from classpath) views, abstracted common view code and
> componentised
> actions.xml, what else do we need to do?
Mike is bringing u
m sure.
-Pat
- Original Message -
From: "Rickard Ãberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 30, 2002 7:39 AM
Subject: Re: [OS-webwork] Rethink
> boxed wrote:
> >>* Chaining. IMHO this needs a big rethink, and most of
boxed wrote:
* Chaining. IMHO this needs a big rethink, and most of all we need to
check: what are the usecases to be implemented.
What would be an alternative way of doing chaining? Your example where the
chaining is done in code and is specified by the action itself is just not
acceptable for
> * Chaining. IMHO this needs a big rethink, and most of all we need to
> check: what are the usecases to be implemented.
What would be an alternative way of doing chaining? Your example where the
chaining is done in code and is specified by the action itself is just not
acceptable for me, as it w
On Mon, Dec 30, 2002 at 02:30:18PM +0100, Rickard Öberg wrote:
> Philipp Meier wrote:
> >My favourite usecase is the show-edit-update-show usecase. Which means
> >having the need to pass the primary key of the object updated to the
> >action show which is the view of the Update action. Views.propt
On Mon, 30 Dec 2002, [UTF-8] Rickard Ãberg wrote:
> Joseph Ottinger wrote:
> > Well, note the quotes I used. "Correctness" can be taken a lot of ways.
> > What I was referring to was buzzword-compatible correctness, where the
> > comp sci grads are happy applying all of their new-found knowledge
Joseph Ottinger wrote:
Well, note the quotes I used. "Correctness" can be taken a lot of ways.
What I was referring to was buzzword-compatible correctness, where the
comp sci grads are happy applying all of their new-found knowledge in ways
that end up making the product less usable. Between usabi
Philipp Meier wrote:
* Commands. Having two actions on a page both using commands doesn't
work. Generally this feature feels a little weird.
Rickard, I don't really understand what you mean by "two actions on a
page". Could you please explain this to me?
If you have a JSP that does include of
On Mon, 30 Dec 2002, [UTF-8] Rickard Ãberg wrote:
Man, you REALLY need to get rid of that wacky "o" you use. :) :) :) *duck*
*run* *dodge* *splat!* :)
> >>Joseph Ottinger wrote:
> > I'll wait for more on this. I really don't like the idea of webwork
> > focusing more on doing it "correctly" than
Joseph Ottinger wrote:
Joseph Ottinger wrote:
* Validation. Clunky design, and not enough loosely coupled to the action.
I personally *like* how webwork currently handles validation. This is one
of Struts' weakest points, and webwork's solution rocks. How would you
suggest it be done?
There
On Mon, Dec 30, 2002 at 12:17:25PM +0100, Rickard Öberg wrote:
> About the design of XWork.
After staying away from ww for some time I'm happy to comment on this
;-)
> * Commands. Having two actions on a page both using commands doesn't
> work. Generally this feature feels a little weird.
Ricka
On Mon, Dec 30, 2002 at 01:32:08PM +0100, Rickard Öberg wrote:
> Joseph Ottinger wrote:
> >>* Validation. Clunky design, and not enough loosely coupled to the action.
> >
> >I personally *like* how webwork currently handles validation. This is one
> >of Struts' weakest points, and webwork's solutio
On Mon, 30 Dec 2002, [UTF-8] Rickard Ãberg wrote:
> Joseph Ottinger wrote:
> >>* Validation. Clunky design, and not enough loosely coupled to the action.
> >
> > I personally *like* how webwork currently handles validation. This is one
> > of Struts' weakest points, and webwork's solution rocks.
Mike Cannon-Brookes wrote:
Packaging I would define as the ability to create 'components' consisting of
WW actions, configuration for those actions and the views. With Velocity
(loaded from classpath) views, abstracted common view code and componentised
actions.xml, what else do we need to do?
T
Joseph Ottinger wrote:
* Validation. Clunky design, and not enough loosely coupled to the action.
I personally *like* how webwork currently handles validation. This is one
of Struts' weakest points, and webwork's solution rocks. How would you
suggest it be done?
There needs to be a way to sepa
Rickard,
Great ideas all - I think you and Patrick are on the same wavelength with a
lot of the Xwork ideas, you're just coming at them from different angles!
As for packaging, I think this is perhaps the coolest feature of Tapestry
that WW doesn't have yet - and Xwork will get sooo close.
Packa
On Mon, 30 Dec 2002, [UTF-8] Rickard Ãberg wrote:
> About the design of XWork.
>
> While WebWork was pretty ok, some of the features that were put in are
> not optimally designed. Here are some of the things I'm concerned about:
> * Commands. Having two actions on a page both using commands doesn
About the design of XWork.
While WebWork was pretty ok, some of the features that were put in are
not optimally designed. Here are some of the things I'm concerned about:
* Commands. Having two actions on a page both using commands doesn't
work. Generally this feature feels a little weird.
* Val
44 matches
Mail list logo
