I made getService() public

[Baz]

For my current app, I am not using a bean factory. I don't need nor want one (for now). FW1 is especially well suited for this, since it auto-caches your services for you, and let's you access them using service(), without having to list them somewhere yourself. 

Where you start to run into problems, however, is if you need to use the result of one service in another service. You can't do this by using the startItem(), item(), endItem() constructs with service(), because no matter where you queue up the service, they will always run at the same time, and once they run, giving you the result you need, you can no longer queue up other services.

The only solution is to bypass the service queuing system, by invoking one or both of your services directly, without using service(), as the FW1 example apps do often. But how do you get to your services? When you use service(), FW1 uses it's snazzy, auto-generated internal collection of your services. If you don't use service(), however, FW1 doesn't expose its snaz-collection in any way, so you have to roll your own. You have to start introducing ColdSpring or DI/1, or at minimum just listing your services in app scope - essentially duplicating what FW1 has already done.

Instead of adding all that kludge, I decided to simply make getService() public, and it seems to neatly solve all the problems:

result1 = variables.fw.getService('service1').load();

result2 = variables.fw.getService('service2').process(result1);

Any reason why I have to be sneaking around the seedy underbelly of society to achieve this? What do you guys think of exposing some methods to get at the collection of services?

Cheers,

Baz

[Nathan Dintenfass]

You are better off creating a very lightweight bean factory that
implements the couple of methods that FW/1 needs -- it can then just act
as a "bucket of services" in the way you want without having to break
the standard framework.

I have talked about the one I made on this list before, but you can grab
the code here:

https://github.com/HotelDelta/FW1-Miscellany/blob/master/servicefactory.cfc

Using that I can do this in my Application.cfc file:

setBeanFactory(createObject("component","model/servicefactory").init());

I then use my "registerService" method to stick references to my
services into my beanFactory. From there you can do what FW/1 expects,
including using getBeanFactory() yourself.

I take a shortcut by doing this in the init() method of a baseController
that all my controllers extend:

variables.fw = arguments.fw;
variables.services = variables.fw.getBeanFactory().getRegisteredServices();

Then in my controller methods I can just say:

rc.foo = services.myService.someMethod();

You could make one that's even simpler than the one I did that JUST
implements the FW1 methods.

> --
> FW/1 on RIAForge: http://fw1.riaforge.org/
>
> FW/1 on github: http://github.com/seancorfield/fw1
>
> FW/1 on Google Groups: http://groups.google.com/group/framework-one

[Baz]

You are better off creating a very lightweight bean factory that implements the couple of methods that FW/1 needs

It's not hard to get around the issue, I definitely don't think I'm better off though. I mainly would like to know why using my service on my own time is worse than using the exact same service on FW1's schedule.

[Nathan Dintenfass]

There's no reason to use queued services if that doesn't feel right for
your app (it seems few do), but I was talking specifically about being
"better off" with a beanfactory than changing the underlying framework.
Otherwise, you might as well just cache your own singletons in the
application scope and call them that way from your controllers.

My point was simply that FW/1 already provides an easy way to do that
while doing things within the framework conventions -- and doing that
might pay off down the road idiomatically and for readability.

[Sean Corfield]

On Sun, Feb 26, 2012 at 12:59 PM, Baz <b...@thinkloop.com> wrote:
> introducing ColdSpring or DI/1, or at minimum just listing your services in
> app scope - essentially duplicating what FW1 has already done.

DI/1 and ColdSpring do something very different - they manage
dependencies between elements of the model.

Once you move away from service queuing, you will find the interim
period before you _need_ that dependency management is very short.
That's why getService() is not public - it's use should not be
encouraged because auto wiring via a DI / bean factory is a much
better solution and you'll need it anyway.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Baz]

How does queuing services or not relate to whether they may need dependency management? They seem to be two separate things. I could have very complex services whose function calls are queued, or whose functions are called directly. And I could have simple services that may need to be called directly, or are better off queued. I'm not seeing how the complexity of a service relates to how I want to invoke its methods. 

I'm really asking to get a better understanding.

Is it perhaps that the whole queuing of services is not that great? First they happened automatically, now by default implicit services are off, maybe in the next version we just get rid of queuing services and service management all together? Mapping service functions to controller functions isn't that great a practice imho.

Thanks,

Baz

 

[Baz]

In case anyone's following, I think I got all my answers from this thread:  http://groups.google.com/group/framework-one/browse_thread/thread/574701ebc4fb2de0/ddae558ff28c81be?lnk=gst&q=queuing#ddae558ff28c81be 

The take-way: basically forget about the service() architecture completely. The fact that it's there and provides basic service management is an anomaly.

From Sean:

"I have abandoned the concept of queuing up service calls completely for FW/1 on Clojure"

"If I had the chance to do FW/1 over from scratch, I would not implement the services convention - I would push people to a single model/ folder and encourage folks to manage service calls directly, using a simple DI framework (so I would have made DI/1 a couple of years earlier :) "

This makes sense to me. I really would vote to get rid of it next version, or at least make it much less prominent in the docs - I think it adds more confusion than it solves.

BTW, I really love FW1, I hope none of this comes off as derogatory.

Cheers,

Baz

[Sean Corfield]

On Tue, Feb 28, 2012 at 9:13 PM, Baz <b...@thinkloop.com> wrote:
> This makes sense to me. I really would vote to get rid of it next version,
> or at least make it much less prominent in the docs - I think it adds more
> confusion than it solves.

Yup. It was a failed experiment. The intent was to avoid boilerplate
controllers that simply delegated to service calls - which I'd seen a
lot in MVC code 2-3 years ago. Nowadays people don't make that mistake
so much (they structure their controllers and services differently) so
it's not a feature that's needed so much.

[Sean Corfield]

On Tue, Feb 28, 2012 at 8:32 PM, Baz <b...@thinkloop.com> wrote:
> How does queuing services or not relate to whether they may need dependency
> management?

The queuing mechanism was intended for simple service usage - you've
already hit its limitations. In the simple world, DI is also not
needed. As I said, by the time you hit the limitations with the simple
queuing convention, you're only a short distance from also needing DI.
That's the only connection. In other words, you run into both
limitations around the same time in the grand scale of things.

> Is it perhaps that the whole queuing of services is not that great? First
> they happened automatically, now by default implicit services are off, maybe
> in the next version we just get rid of queuing services and service
> management all together? Mapping service functions to controller functions
> isn't that great a practice imho.

Yup.