I don't have any resources to offer as all the apps I've done along
these lines have been custom jobs. I have a rather substantial library
that I've built up over the years or client-side functions, widgets and
sich, as probably anyone who's done apps like this has, but none of it
is published
SF,
Struts-Scripting[was Re: Proposal: |
| Javascript-to-Java object conversions]]])
|
>---|
On Tue, 2 Nov 2004 21:43:41 -
On Tue, 2 Nov 2004 21:43:41 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote:
> This is a really interesting statement. Perhaps I'm wrong, but I've
> always thought the whole point of JSF was visual components. Yet the
> statement above clearly indicates that JSF goes well beyond that
> charter, and
In order to meet the spec requirements for handling server side events
related to the view tier components, JSF also provides a front
controller responsible for handling the server side request processing
lifecycle, with event listeners and other plug-in points for either
application code or contro
> statement above clearly indicates that JSF goes well beyond that
> charter, and clearly suggests that there are facets of JSF that should
> not be a part of that JSR.
>
>From the original design goals of JSR 127 (JSF)
"Provide a JavaBeans model for dispatching events from client-side
GUI contro
On Sun, 31 Oct 2004 23:00:41 -0700, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On Sun, 31 Oct 2004 21:30:22 -0600, Eddie Bush <[EMAIL PROTECTED]> wrote:
> >
> > Unless Martin is incorrect about the way JSF handles requests, I'm inclined
> > to believe (despite the fact JSF will be a part of the
I started toying with this today... The first problem I found is that if
you set the value of a form field to an object (i.e.,
theForm.myField.value = myObject;), you DON'T get it serialized as was
indicated originally... You simply get the typical [Object] string. At
least, this is the case i
On Sun, 31 Oct 2004 21:30:22 -0600, Eddie Bush <[EMAIL PROTECTED]> wrote:
>
> Unless Martin is incorrect about the way JSF handles requests, I'm inclined
> to believe (despite the fact JSF will be a part of the next specification)
> we might want to consider using something else under the covers i
ist" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, October 31, 2004 7:03 PM
Subject: Re: JSF and highly dynamic apps (was Re: Struts-BSF,
Struts-Scripting [was Re: Proposal: Javascript-to-Java object
conversions]]])
Martin, you make an interesting comment that I thi
Martin, you make an interesting comment that I think ties into this
discussion (loosely ;) ) that is worth mentioning...
A lot of the tools us architects and developers use these days really
only make sense in cases where you have a separation of activities in
terms of page authors and develope
I hear what you're saying, Craig. However, I still feel that JSF
doesn't buy me much when building highly dynamic apps. Some points to
consider:
* Since one of the goals of such apps is to minimise the number of
full page refreshes, relatively little of the app can be constructed
using tools such
MAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Sunday, October 31, 2004 12:18 PM
Subject: Re: Proposal: Javascript-to-Java object conversions
On 29 Oct 2004, at 22:46, Ted Husted wrote:
On Fri, 29 Oct 2004 14:01:36 -0700, Don Brown wrote:
Struts Flow
On 29 Oct 2004, at 22:46, Ted Husted wrote:
On Fri, 29 Oct 2004 14:01:36 -0700, Don Brown wrote:
Struts Flow will be added to Struts soon as an official sub-
project, as will Struts BSF
I was getting ready to mention that the Guiness clock is ticking, in
case you still wanted to have these in pl
On Sat, 30 Oct 2004 11:03:29 -0700, Martin Cooper <[EMAIL PROTECTED]> wrote:
> To my knowledge, anyway, JSF is page oriented, relies on a page's
> component tree for rendering / processing, and does not provide for a
> client-side component to communicate back to its server-side partner
> without s
On Sat, 30 Oct 2004 14:33:12 -0400, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> Martin Cooper wrote:
>
>
> > The app you describe does sound a little more extreme than one might
> > want, but I think it's a great illustration of what can be done with
> > JavaScript on the client. The primary a
Martin Cooper wrote:
The app you describe does sound a little more extreme than one might
want, but I think it's a great illustration of what can be done with
JavaScript on the client. The primary app I work on in my day job also
uses huge amounts of client side JavaScript to give the user a
near-d
On Sat, 30 Oct 2004 00:50:17 -0400, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> I need to look at those links in a little more detail... At a glance I'm
> not sure they fulfill the same goal (although they look to be without a
> doubt very cool!)... I need to evaluate them more though to be sure
I need to look at those links in a little more detail... At a glance I'm
not sure they fulfill the same goal (although they look to be without a
doubt very cool!)... I need to evaluate them more though to be sure.
I agree 100% with your comment about remote scripting... I think there
was a big
I'm personally fond of vcXMLRPC - http://www.vcdn.org/Public/XMLRPC/ -
and have used it successfully in several projects, an ASP application
and a Struts-based application. I've heard of others, but that one
has been good to me as it works with IE 5.5+ and Mozilla 1.0+.
This also seems to be a go
It sounds like what your saying is that such a beast already exists...
I'm looking now at the XML-RPC site at http://ws.apache.org/xmlrpc/,
specifically the link to Client Classes... Is this what your referring
to? If so, I think this is dealing with writing a Java-based client,
not Javascript
On Fri, 29 Oct 2004 23:52:49 -0400, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> Argh, posted to the wrong list!
>
> Well, in all honesty, this isn't something that was initiated by me,
> I've never had a thought of passing objects back and forth, so I'm not
> sure I can give you a real, concret
Argh, posted to the wrong list!
Well, in all honesty, this isn't something that was initiated by me,
I've never had a thought of passing objects back and forth, so I'm not
sure I can give you a real, concrete use case that would explain it. I
certainly hear what your saying about XML. I mysel
On the later idea, I intend to put together a proof-of-concept next week
when I get back to the office. I have some family engagements this
weekend that will keep me from getting started, and on Tuesday I take
the first exam for my SCEA (not to mention the election!), but I have
some spare cyc
On Fri, 29 Oct 2004 21:28:52 -0400, Ted Husted <[EMAIL PROTECTED]> wrote:
> That sounds great to me, Don. :)
>
> We already have Struts-Faces and Struts-Examples on the trunk. We might as well add
> Struts-BSF and Struts-Flow to the mix.
+1.
>
> Struts-BSF and Struts-Flow are not part of the c
That sounds great to me, Don. :)
We already have Struts-Faces and Struts-Examples on the trunk. We might as well add
Struts-BSF and Struts-Flow to the mix.
Struts-BSF and Struts-Flow are not part of the core, so they would be not affected by
a 1.2.x branch.
-Ted.
On Fri, 29 Oct 2004 14:59:18
DHTML and javaScript from Java and vis versa
Cheers
Alan
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 29 October 2004 21:13
> To: [EMAIL PROTECTED]
> Subject: Re: Proposal: Javascript-to-Java object conversions
>
>
> I do have so
Hey, I'll could do that this weekend, but I thought I was to wait until
1.2.5 was rolled, which has, well, stalled. Damn you and your dark,
velvety carrot. :)
Don
Ted Husted wrote:
On Fri, 29 Oct 2004 14:01:36 -0700, Don Brown wrote:
Struts Flow will be added to Struts soon as an official su
On Fri, 29 Oct 2004 13:12:39 -0700 (PDT), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> I do have some experience with Rhino, I actually integrated it into DataVision a few
> weeks ago for Javascript formula support (new release coming at some point!). I
> hadn't considered it for this... I'll
On Fri, 29 Oct 2004 14:01:36 -0700, Don Brown wrote:
> Struts Flow will be added to Struts soon as an official sub-
> project, as will Struts BSF
I was getting ready to mention that the Guiness clock is ticking, in case you still
wanted to have these in place by ApacheCon :)
>> And if Don wants
Ah, ok, that's what I get for just skimming :) Your understanding is
correct.
Speaking to serializing of client-side javascript objects, it is an
interesting idea and I would be interested to see a proof of concept.
The two alternatives I have used in the past for passing complicated
data st
> However, I think there is still some debate to be had
> about whether such functionality makes sense in the core of Struts (I'm
> starting to think not myself, but it's probably debatable).
Yes, this was my first reaction, too, that something like this
sounds like it /doesn't have to be//shoul
Hmm...good question. :) Struts BSF is a very simple project that lets
you write a Struts action using a BSF-supported scripting language. The
advantage of this project is you can use any BSF-compatible language
including Python, Ruby, Groovy, Javascript, Perl and even VBScript (on
windows).
I can only comment on my proposal as I don't know anything about Flow...
You are correct, the goal is converting client-side objects to
server-side ones (and vice-versa). Beyond that I can't really comment.
You are correct in that the client-side objects get serialized and then
submitted, wher
Don, Frank,
My understanding of the proposal is that its goal is to somehow
convert client-side javascript objects to server side java objects,
and my understanding of Struts flow is that it uses server side
scripting languages in place of precompiled java classes. Am I
correct on both counts? I
Struts Flow allows you to use a Javascript function to replace a
Struts action. I use iBATIS to run SQL queries and return Lists of
Maps (a Map keyed by column names in the result set), then feed
those Maps to the JSP. Struts Flow provides a jsobjectToMap
function that lets you convert a Java
I didn't see anything in that proposal that couldn't be satisfied by
Struts Flow, but I could have missed something. If so, we could
supplement Struts Flow to support it. Converting Javascript objects to
Maps should be a sufficient way to handle compatibility with existing
Struts capabilities
That sounds pretty cool Don! I guess it leads to the question (for you
Struts committe members, not me) whether what you describe suffices and
just leave it at that for anyone that ever needs this capability, or
whether this whole serialization idea makes sense included in Struts.
I guess the
Yep, I agree on the Map point, that's why I mentioned maybe just a
HashMap would suffice. I had some doubt only because I'm not familiar
yet with how the converter gets written (I just looked at the javadocs
for the first before I write that proposal, just to get a rough idea).
As for the type
Actually, I just wrote a web application that uses Struts 1.2.4, Struts
Flow - http://struts.sf.net/flow , iBATIS database layer, and a touch of
Java. Struts Flow allows you to use a Javascript function to replace a
Struts action. I use iBATIS to run SQL queries and return Lists of Maps
(a Ma
Wouldn't a Map that had String-valued keys be a reasonable Java object
representation of a JavaScript object? That way you can have an
arbitrary set of properties, and deal with them by name instead of by
index. In the JavaScript->Java direction, you'd probably make the
values all Strings too (un
I do have some experience with Rhino, I actually integrated it into DataVision a few
weeks ago for Javascript formula support (new release coming at some point!). I
hadn't considered it for this... I'll have to think about it a bit. Off the top of my
head it seems like it might be a little hea
Have you looked at Rhino http://www.mozilla.org/rhino/ ? It lets you
access Java from JS and JS from Java so you might not need to handle types
if you just pass the JS into the Rhino interpreter.
I'm not sure I understand the use cases for your proposal though.
David
--- [EMAIL PROTECTED] wro
42 matches
Mail list logo
