Ah, they look exactly like PropertySets: http://www.opensymphony.com/
propertyset. PropertySets can have memory/map implementations (like a
DynaBean) or can have persistence implementations (EJB, JDBC, etc).
Yeah, I think adding support would be _really_ easy.
Patrick
On Jan 5, 2006, at 2:36 PM, Don Brown wrote:
http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.7.0/
docs/api/org/apache/commons/beanutils/DynaBean.html
DynaBeans aren't really a Map (but they may use one internally for
storage, and require a backing DynaClass to define their structure
and data types.
Don
Patrick Lightbody wrote:
Pardon my ignorance, but is there some link that describes what
DynaBeans are? Currently WW's ValueStack is able to populate Map
structures if they are in the value stack. Ie: foo.action?bar=baz
will call map.setBar("baz") if a Map is in the stack.
On Jan 5, 2006, at 2:17 PM, Don Brown wrote:
Good question. DynaBeans might still be valuable if you use
them further down in your application or generally prefer
working with Map-type structures. If they are only used to
avoid having to write forms, then, correct, they won't be of
much use in XWork.
If folks don't think Action 2.0 should support DynaBeans in
core, I'm fine leaving them in the legacy package, which
supports the ability to run ActionForms and DynaActionForms
unmodified in Action 2.
Don
Laurie Harper wrote:
Ex-party sidebar: how much value do DyanBeans add in WW given
that, if I understand correctly, it can already work directly
with POJOs? The thing that dyna action forms are there to
avoid (writing boilerplate action forms) isn't needed in WW is it?
L.
Don Brown wrote:
Off the top of my head:
- Wildcards
- Chain command executed from Interceptor (like ChainInterceptor)
- Chain command executed as Action (an alternate
implementation of ActionInvoker)
- DynaBean support in ognl
- Package properties support (debatable)
Don
Patrick Lightbody wrote:
Duh, sorry about that. It's been a slow day :)
Can we talk about more about #7? I think #7 is where the
majority of the time (debate time or development time) will
be spent. What items do you guys have in mind?
Patrick
On Jan 5, 2006, at 12:05 PM, Ted Husted wrote:
On 1/5/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
I know there are a few features (probably more) that we'd
like to
bring forward from Struts Action 1.x to 2.x that aren't in
WebWork
already. For example, the wildcard support in configuration.
Where does that fit in? This current schedule looks like
2.0.0 would
be basically WebWork 2.2 + migration tools. Is the plan to
add the
extra features, like wildcards, to Struts Action 2.1? I'm
find with
either, but my understanding was that we'd do additional
development
between WW 2.2 and SAF 2.0.
That would be item # 7.
7. Migrate Struts features as desired (chain support,
wildcards, etc)
We're going to need at least two phases of development
between WW 2.2
and SAF 2.0.0.
First, we need to replace the LGPL dependencies and resolve
any other
IP/Incubator issues (Item #2).
Second, we would add any missing features, like
wildcardmappings (Item #7).
Of course, some of this will be asynchronous. Don and Rich
are doing
some early work on tools now, but those would change as we
add missing
features.
-T.
----------------------------------------------------------------
-- ---
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-----------------------------------------------------------------
-- --
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-------------------------------------------------------------------
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
