It sounds like you're tackling the general problem of pulling external data into FarCry. I think Geoff is pointing out that forms are an ideal way of defining data structures to attach webskins to. If you find that the data is too complex for a flat data structure you can could related forms or use stParam to pass in extra info.
In terms of accessing the external data, I would say "best practice" is to create a custom component as a wrapper to all calls to the external source. Load that into application.oFactory (or something) on application init. Then access all external data through that component, be it from dmInclude, a rule, or a user directory. We haven't really abstracted the idea more than that. Every case involves different data / output / integration. Blair On Thu, Mar 5, 2009 at 4:20 PM, AJ Mercer <[email protected]> wrote: > Hi Geoff, > > The form.process() only populates the forms fields > The data I am dealing with has compex data types - arrays, queries, structs > > > I am not sure why you are trying to move my away from dmInclude / > wbxprocess way of doing it. > Is there something wrong / bad about this approach? > > Though I am concerned about getData() being called multiple times per page > > > 2009/3/5 modius <[email protected]> > >> >> On Mar 5, 2:59 pm, AJ Mercer <[email protected]> wrote: >> > The content I want to display does not come from Farcry (I am consuming >> a >> > webservices) so there is no CFC and therefore now webskins directory. >> > >> > I could perhaps created a generic type?? >> > All the web service calls are done though a single API, so I guess I >> could >> > base the component on what is required to make a call to that. >> > But each call returns different data attributes >> > >> > So what I am trying to achieve is have a way to load external (not from >> > Farcry) data, load it up into stOBJ, then let Farcry do it's magic with >> > webskins to render that data - just as if it came out of dhHTML. >> >> Hmm.. that's a good question. I think I'd be recommending the use of >> FarCry "forms". A "form" is in essence a content type that is not >> persisted in the database. Although it was not our original >> intention, it appears that "forms" are actually an ideal way of having >> all the normal content type functionality you might want (eg, >> formtools, views, caching, etc) without having a corresponding >> persistence layer in the database. >> >> Got no documentation on forms for you handy. Except they are just >> like content types, and are stored in ./packages/forms >> (http://docs.farcrycms.org/display/FCDEV50/Form+Components is what we >> wrote up whilst building Fortress) >> >> Configs are a special "form", prefixed with config* For example, ./ >> packages/forms/configMySpecialConfig.cfc >> >> -- geoff >> http://www.daemon.com.au/ >> >> > > > -- > AJ Mercer > Web Log: http://webonix.net > > > Once you come to the realisation that everyone is crazy, > You will never be surprised or disappointed ever again. > AJM 2008 > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "farcry-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/farcry-dev?hl=en -~----------~----~----~----~------~----~------~--~---
