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.
> 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)
> 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. 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.
Aside from that one quibble, this all sounds quite good to me.
> /Ian
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
