RE: Using Flash MX as a front end

[Bruce Altner]

Thanks, but while executeQuery() does return a vector of Record objects (as does doSelect) it does not take a Criteria object as its argument. Meanwhile, it appears that there is another method, doSelectVillageRecords(), which does take Criteria and returns a Vector of Record objects. According to the docs, these are the "the raw Village records to be formed into objects". Is this what you meant?

I'm still not sure how to map this to ResultsSet but at least this gives me a direction to start investigating.

Thanks again,
Bruce




At 12:17 PM 1/14/2003, you wrote:

I'm experimenting with something similar. Flash Remoting not being in the budget for me, i'm taking the poor man's approach.

Basically what i do is take the Lists (i'm using tb 2.2) that i would normally put in the context, and i encode them and pass them as one big url-encoded string. That way i can get them into flash via LoadVars(). So my logic stays the same, i'm just passing data to the context in a different format.

a) Design pattern?
If u want to get into patterns (i'm new at the pattern stuff too), i suppose what i described would be similar to the adaptor pattern.

b) Vector and ResultSet
If u use the executeQuery() method of your peer instead of the doSelect() it will return village Record objects, which may be easier to map to javax.sql.ResultSet.

hope that helps.

-----Original Message-----
From: Bruce Altner [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 13, 2003 6:18 PM
To: Turbine Users List
Subject: Using Flash MX as a front end


Greetings:

I have been asked to refactor my successfully deployed Turbine/Velocity
application so that another customer could reuse most of the code but put a
glitzier front end on it using Flash MX. To accomplish this I have been
investigating the Flash Remoting MX tool, which provides a "web services"
gateway between the Java class files and Flash's ActionScript objects.
Initial tests are very promising but I have two questions that I'm hoping
folks more experienced than I can help with:

a) Design pattern?

Rather than rewriting all the logic code, I think the right way to do this
is to build an interface layer that will allow me to use the same code with
either Velocity templates OR Flash Actionscripts, depending on
configuration parameters in TRProps. My guess is that this is a pretty
common situation in the OO world so there is probably an existing design
pattern that addresses this need directly. Adapter? Abstract Factory? I'm
kinda a beginner with patterns but this seems like a situation tailor made
for picking the right one. Ideas?

b) Vector and ResultSet

For the deployed application I'm using Criteria for all my db calls and
wind up putting Vectors and Hashmaps into the context to be processed by
Velocity. But Flash Remoting provides a ResultSet actionscript object that
maps directly to javax.sql.ResultSet so for the new UI I'd probably want to
send ResultSet objects back and forth. However, I'd like to avoid rewriting
all the queries that presently return vectors (e.g.
xxxxPeer.doSelect(criteria)). So, is there some way to magically transform
the output from Peer class-based queries into javax.sql.ResultSet objects
or is that too farfetched?

Thanks, in advance, for suggestions on either issue.

Bruce


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>