Model access

[Wally]

How do I call functions in my model?

[Brian Meloche]

Wally,

That's a good question. I'm not being facetious. I was waiting for someone to ask that question because that's something not currently well defined yet in LightFront as to how.

Partially, that is by design. LightFront doesn't care about your model, so it's specifically ignored in the current skeleton and sample application.  It's pretty open ended and left up to the developer.

OK... now that I've not answered the question, I'm waiting on some feedback from users of LightFront on how to go forward with the model.

The options that I can think of (I'm open to other options):

1. Keep it open ended.  Provide some samples on how you might apply the model, and whether you use a factory or not, framework or not.
   
2. Keep it out of the framework, but define best practices on how to apply the model in LightFront. You would be free to opt out of the best practices and come up with your own thing, but if you run into issues, you might be on your own.
3. Build a way to interact with your model into LightFront. You could do it similar to the way Sean's done it in FW/1 and provide a services layer. Since the code for loadControllers() does this now for the controller CFCs, this would be fairly easy to implement. However, you might design yourself into a bit of a hole if you specifically build it so LightFront doesn't use a framework like ColdSpring for your model.
4. Build a plug-in to interact with the model, optional in LightFront, to work with ColdSpring and LightWire.
5. Build a requirement to use ColdSpring or LightWire into LightFront. I'm not exactly in favor of this approach, as it goes against the reasons why the framework exists in the first place - to eliminate the crap of using a framework and give you a standard MVC architecture that's fast, easy to understand and easy to use.
   

I don't like #5, and as long as I'm the lead developer of LightFront, that's off the table.

#3 doesn't make it all that different to how Sean's done FW/1, and we'd take LightFront down the same road as FW/1. Now, that's not exactly bad, but if both frameworks are essentially solving the same problem, there's not much point in having two frameworks do the exact same thing. If that's the solution, we should be looking at merging the two frameworks at some point.

Short term, I'd say it's #1, possibly moving to #2 if we get a uniform way on how to do this.

Longer term, I started working on LightFront with #2 and #4 in mind. I like both approaches a lot, and it will help keep the framework light (light as in lightweight).  As in...

"Need to integrate ColdSpring into LightFront? No problem, here's an example how it was done here, and here's a tutorial on how to implement it."

"Need to integrate ColdSpring with Co-op? No problem, John's built a plug-in specifically to do that, and you can get it here."

I know I didn't directly answer your question, Wally, but I wanted to get the ball rolling on such ideas on how to move forward with LightFront.

I'll answer you better in the next reply.

Sincerely,

Brian Meloche
brianmeloche at gmail dot com
Producer and Host, CFConversations Podcast
http://www.cfconversations.com
Blog: http://www.brianmeloche.com/blog/
Adobe Community Expert:
http://www.adobe.com/communities/experts/members/BrianMeloche.html
Twitter: http://twitter.com/coofuushun
User Group Manager,
Cleveland ColdFusion Users Group,
http://www.clevelandcfug.org
Creator, The LightFront MVC Framework for CFML
http://lightfront.riaforge.org/

[Brian Meloche]

Wally,

Sorry, I was going to add a second reply, but I've been busy on a couple of things. I apologize for keeping you waiting.

A better answer to this is how would I interact with the model TODAY. I'm working on another sample application that will try to address this question a lot better. It won't be THE ANSWER. The real answer, at this point, is that there IS NO answer defined within the framework. You are free to interact with the model anyway you want. Typically, you would do this by calling the model from the controllers, like other MVC frameworks do.  You are encouraged to do so with controller CFCs that interact with service CFCs that deal with the rest of your model.  The sample will show how *I* would interact with the model, but you are free to choose your own path.

LightFront also lets you interact with procedural models, even in a controller CFC, so that's where LightFront's a little different. I'm not saying that's the way to do it, but that is a way you can work with your old apps and not have to rip them completely apart to use LightFront. It's a pragmatic solution, and one that gives you some flexibility to slowly refactor your applications over time.

I've made a few updates to the framework the last couple of days that I haven't committed yet, so you should expect them in the next few days once they've been more fully tested. The updates address nested layouts (which didn't quite work the way I had expected), as well as some additional settings.

Sincerely,

Brian Meloche
brianmeloche at gmail dot com
Producer and Host, CFConversations Podcast
http://www.cfconversations.com
Blog: http://www.brianmeloche.com/blog/
Adobe Community Expert:
http://www.adobe.com/communities/experts/members/BrianMeloche.html
Twitter: http://twitter.com/coofuushun
User Group Manager,
Cleveland ColdFusion Users Group,
http://www.clevelandcfug.org
Creator, The LightFront MVC Framework for CFML
http://lightfront.riaforge.org/