mla (maurice.a...@gmail.com)

Cédric Bouvier wrote:
> Unfortunately, the requirements just included a WSDL file, and the words
> "implement that!". So we were doomed. The pressure and lack of sleep
> must have blinded me, for I didn't give up at once, and wasted valuable
> time trying to get something working.

I'm no expert on SOAP, but I have had success working
with a .net server and WSDL file simply using this:

   my $soap = SOAP::Lite->service($path_to_wsdl_file);
   $soap->envprefix('SOAP-ENV');

The envprefix was the trick.

Maurice

Yes, I like that point.

>> In terms of testing, seems like the singleton is a bit better since you
>> have no ACCEPT_CONTEXT method to test.
>
> Separating out the interrogation of the context and retrieval of data into
> the ACCEPT_CONTEXT is how you avoid loose coupling - and it also then means
> you know you have -one- method that requires a mocked $c to test rather
> than potentially any in your entire codebase needing that.

Avoid loose coupling? You mean tight?

I was thinking you're basically pushing the mocked $c testing to the
singleton class. If it works, then any code that uses it should work.
The retrieval of the data is already handled for you (by the singleton).
You just have to interrogate it, so one less piece.

>> I don't see how debugging would be any harder.
>>
>>> I prefer anything a method call needs to have been either (a) passed to the
>>> object when it was constructed or (b) passed to the method as it's called.
>>>
>>> It can be a bit more work up-front but it makes you think about your
>>> architecture, which I find pays off down the road.
>> A method call could also need to have access to other modules/packages
>> it will delegate to. The singleton seems equivalent.
>
> I don't do that either. I generally create associated objects via factory
> methods and have an attribute for the related class with a default.
>
> An example of this would be the _action_class member of Catalyst::Controller,
> which is what defaults you to Catalyst::Action as your action class - related
> classes should -always- be overridable.

There are lots of cases where you wouldn't do that though.

Like if you need to make some directories, you're not going to have a
new_file_path_like_object() methods and a default_file_path_class().
You're just going to use File::Path.

But your point being that you want your models to work with any
Catalyst-type-thingy, rather than assuming it's part of your Catalyst
application? Hmmm.

So what do you think of things like Perl's @INC? How would you implement
it without the equivalent of a singleton class?

And if a class wanted to access it, would you write something equivalent
to an ACCEPT_CONTEXT method that would be passed the Perl environment?

But if you are going to use ACCEPT_CONTEXT then you are tightly
coupling the model to the application.

I agree that should be avoided... but they are equivalent if not
more tightly coupled by adding the context to the actual model instance.

I'm not sure about the "action at a distance' thing. Also seems pretty
equivalent. You have this outer context thingy making a call into a
magical model method so it can add a singleton to itself. ;-)

In terms of testing, seems like the singleton is a bit better since you
have no ACCEPT_CONTEXT method to test.

I don't see how debugging would be any harder.

> I prefer anything a method call needs to have been either (a) passed to the
> object when it was constructed or (b) passed to the method as it's called.
>
> It can be a bit more work up-front but it makes you think about your
> architecture, which I find pays off down the road.

A method call could also need to have access to other modules/packages
it will delegate to. The singleton seems equivalent.

I agree that having the singleton does make it easier to couple too
tightly though.

Ah, okay. So it really is just a wrapper to allow it to be plugged in.
Cool :-)

Leo Cacciari wrote:
> I'm planing to develop a Catalyst::Model::DNS, allowing Catalyst
> applications to access (and update through dynamic queries) a Domain
> Name Service.

What's the benefit of making this a *Catalyst* model? Doesn't that
couple your DNS module to your web framework?

Why not just write a DNS module with all your dynamic update methods
and then add a wrapper to use it as a Catalyst model?