--
From Down & Around, Inc.
Innovative IT Solutions
Software Architecture * Design * Development
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
web: www.fdar.com
email [EMAIL PROTECTED]
phone: 617.821.5430
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--- Begin Message ---
Frank W. Zammetti wrote:
On Tue, May 23, 2006 2:57 pm, Ian Roughley wrote:
What we came up with is:
1. Struts2 should be able to work generically as a data source for any
ajax client. This would entail being able to return HTML and XML
results, but also JSON results. Additionally, as well as populating the
action from the HttpServletRequest we will look into populating it from
JSON and XML (this could be tricky as the XML structure would need to be
defined).
Argh, you guys beat me to the punch! Coincidentally, I had the very early
beginnings of code to do exactly this starting to cooking over the weekend
:) So I guess you can count me as supportive of the idea!
I had taken the cop-out approach though... any field in the Action where a
matching element is found anywhere in the XML, as long as the element only
appears once, is populated. For elements that appear multiple times, it
looks for a Collection or array with a matching name and populates it.
This saves you from having to define the XML structure outright, and
should work the same basic way for JSON as well. The obvious problem is
that it's a little *too* flexible perhaps... I was thinking of providing a
simple mapping file that could be read for any Action mapping, something
like this:
<myAction>
<firstName/>
<children>
<firstName/>
<firstName/>
</children>
</myAction>
My thinking was to create a DTD on-the-fly from this, validate the
incoming request against it, and then pluck the values out and populate
the Action, using the same basic logic as I outlined above. As I wrote
this paragraph, it occurred to me that just providing a DTD straight away
would probably be sufficient. I think it might be easier on developers
those to actually write the XML they expect to receive and save them (as
easy as it generally is) to write a DTD or schema.
I think a separate mapping file adds a little too much complexity.
Initially my thought was to use an XML format similar to that which
XStream produces (very similar to what you have) where an attribute
defined at a particular level will be set on the corresponding
action/object graph.
2. Struts2 should limit the number of ajax libraries it uses.
I would hope you mean limit what libraries it uses by default, not limit
what libraries it *can* use ;) (I know you do)
correct - there may be a need to add in others (perhaps even dojo) for
very specific tasks.
It was
agreed to use DWR as the core library.
Cool! I'm a big fan of DWR, I think that's a fantastic decision. Is the
idea to have the DWR servlet running in the same context as the WW app, or
somehow more directly integrate DWR into WW so the servlet isn't
necessary? I would think a filter approach could work here, without
thinking about it very much. It would also keep WW configuration as far
as web.xml goes as simple as can be.
Joe thought that a Struts2
creator that read could read existing Struts2 configuration files, and
expose a package would be fairly simple to do. This would avoid
additional configurations.
So by default all the Actions would be exposed as, in essence, service
endpoints, in this package? I'm not sure I like that, sounds like a
potential security nightmare.
How do you see this as a security risk? Actions are by default
endpoints - they just take URL/form parameters rather than XML. This
would not be all actions, but actions from a specific package/namespace
(URL path). When developing ajax webwork/strut2 applications I find I
develop them this way anyway - to remove the sitemesh decoration.
Or would you still have to enable what can
be accessed? If you have to still write config to enable things anyway,
I'm not sure how much it would save. I'd like to hear more about how Joe
envisions this working.
3. We should get out off the business of simply wrapping existing
widgets / components when we add no additional benefit to users.
Defining this distinction is a little harder. The easy examples are
obtaining remote content, providing ajax-based select lists (with
backing actions), data backed tables and mouse-over tips (obtained via
remote content) - things that need interaction with the server-side.
Ok... what does everyone think?
I think anyone that makes an Ajax call to retrieve tooltip text is
inherently evil :) LOL I kid, I kid. Seriously though, it's very easy to
abuse Ajax and wind up with a server ground to its knees when the load
gets high enough. Even though each Ajax request is generally smaller and
easier to generate on the server resource-wise than a full page refresh, I
think it is good to try and dissuade people from doing things like getting
tooltip text from the server as a best practice, and therefor not
providing things in the framework that makes it too easy. After all, if
your going to use Javascript to retrieve a tooltip, why not just have it
on the client and generate it there? It's script either way.
ok - you got me here ;-) - I was trying to think of another easy
example. Let's say it's a "tooltip" like alex uses in the infoq.com
discussion threads... which was a really cool usability application when
I first heard about it.
Aside from that one quibble, this all sounds quite good to me.
/Ian
Frank
--- End Message ---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
