In response to your suggestion on implementing more logic on the client side, I'll quickly give you my high level plan.
I agree that the more I can implement in Flex, the better user experience. What I'm brainstorming is that my business rules are implemented on the server side using java. This includes, but not limited, to things like validation. Then, come up with a way to "generate" the business rules from java into action script and/or MXML. IMO, this benefits me in a number of ways: - I get the rich client using flex. - I can maintain my business rules in one central location, on my server side. - I can implement other user interfaces (mobile phone, jsp, applet, web service, etc.) and still have my business rules/logic on my server side. I'd like to hear everyone's opinion on my approach... - Mike ===================================================================== --- In [email protected], "Peter" <[EMAIL PROTECTED]> wrote: > > I was under the impression that in order to use RemoteObject one does need > FDS. Given this (and another) answer and Mike's requirement not having to > rely on FDS, I am confused now. > > Can I conclude that RemoteObject RPC can be used without FDS? I guess I got > confused by what I read in chapter 45, "Using RPC components" of the > devguide. > > > If you are using Flex Data Services, you have the > option of connecting to RPC services > > directly or connecting to destinations defined in the services-config.xml > file or a file that it > > includes by reference. A destination definition is a named service > configuration that provides > > server-proxied access to an RPC service. A destination is the actual service > or object that you > > want to call. A destination for a RemoteObject component is a Java object. A > destination for > > an HTTPService component is a JSP page or another resource accessed over > HTTP. A > > destination for a WebService component is a SOAP-compliant web service. > > > > > > Btw, because I was in the same situation I kind of rolled out my own > approach of POST'ing XML back and forth using HTTPService to a servlet. > Works well, but of course setting up the necessary infrastructure to keep it > all maintainable will require a bit of work. > > > > Also, wrt to the Mike's setup of planning to replace JSP with Flex I can > only gently advice to rethink the architecture a bit. One should, at least I > think, use Flex to implement a bigger chunk of the application logic on the > client side (compared to what one typically does in jsp). That should result > in less (granular) requests being sent to the server and that is after all > how the rich(er) user experience can be implemented. > > > > Peter > > > > _____ > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Dimitrios Gianninas > Sent: Monday, April 30, 2007 9:43 PM > To: [email protected] > Subject: RE: [flexcoders] flex communication > > > > Since you are starting off, I suggest you start small. Just build basic apps > get them to run inside JBoss/Tomcat. Once that works then use the > <mx:RemoteObject/> tag to communicate with a simple Java class and see if it > does what you except, then get more complex from that. > > > > Dimitrios Gianninas > > Developer > > Optimal Payments Inc. > > > > > > _____ > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of vargomike > Sent: Monday, April 30, 2007 3:09 PM > To: [email protected] > Subject: [flexcoders] flex communication > > Hi all... I have lots of questions so I'll first say I appreciate you > taking the time to read and potentially responding to them. I'll be > posting them separately. > > === > We're creating a brand new application from scratch using Flex as our > front end. The back end will consist of JBoss and some relational DB. > > I have lots of experience building typical web apps using JSP, Struts, > etc., but zero experience using Flex. In our app, I picture Flex as > being simply the replacement of JSP pages, i.e. the front-end. > > - What's the best practice to communicate from Flex to an app server > like JBoss/Tomcat? (flex must talk to the Java world) > > Unfortunately, I know that I do not want to use the Flex data services > purely for financial reasons. I have experience in Java, J2EE, EJBs, > etc. so I'm confident I can build the service that flex would talk to. > > Thanks again... > > - Mike > > > AVIS IMPORTANT > > WARNING > > > Ce message électronique et ses pièces jointes peuvent contenir des > renseignements confidentiels, exclusifs ou légalement privilégiés destinés > au seul usage du destinataire visé. L'expéditeur original ne renonce à aucun > privilège ou à aucun autre droit si le présent message a été transmis > involontairement ou s'il est retransmis sans son autorisation. Si vous > n'êtes pas le destinataire visé du présent message ou si vous l'avez reçu > par erreur, veuillez cesser immédiatement de le lire et le supprimer, ainsi > que toutes ses pièces jointes, de votre système. La lecture, la > distribution, la copie ou tout autre usage du présent message ou de ses > pièces jointes par des personnes autres que le destinataire visé ne sont pas > autorisés et pourraient être illégaux. Si vous avez reçu ce courrier > électronique par erreur, veuillez en aviser l'expéditeur. > > This electronic message and its attachments may contain confidential, > proprietary or legally privileged information, which is solely for the use > of the intended recipient. No privilege or other rights are waived by any > unintended transmission or unauthorized retransmission of this message. If > you are not the intended recipient of this message, or if you have received > it in error, you should immediately stop reading this message and delete it > and all attachments from your system. The reading, distribution, copying or > other use of this message or its attachments by unintended recipients is > unauthorized and may be unlawful. If you have received this e-mail in error, > please notify the sender. >
