[Dancer-users] about Dancer

[Alexis Sukrieh]

[ CC'ing to the dancer-users ML as this is of common interest ]

Hi,

Le 07/12/2010 11:32, metys a écrit :
> Hi,
>
> My name is Łukasz Lewandowski, (or "Metys", easier ;-))
>
> I decided to write this mail, because I have few questions/suggestions related to your Dancer framework...
>
> Before I start, I want to say, that I realy like Dancer (currently, is my number one), but...

Glad to see that Dancer fits your needs.

> 1. I don't understand, why treat Dancer::Session as a framework "core" functionality (why you put it tnto Dancer.pm), instead of create a plugin?
> I can live (but don't agree) with that...

That's funny you write about that, because I've wrote an article 
(unpublished yet, be patient ;) for our Advent Calendar[1] about Dancer 
internals. In this article I'll explain all the reasons behind the 
design of Dancer, so I won't detail everything here (don't want to spoil 
our great advent calendar!).

But basically, when I wrote Dancer, I've intetified some common fields 
in web development that I wanted to be very easily integrated with 
Dancer. I wanted also to have the possibility to write multiple backends 
for them, easily, so the CPAN community can extend very quickly our 
namespace (and that did happen, so I guess I was right on this).

That's why the Dancer::Engine strategy wenty into place. You'll have 
details about that design in my upcomong article entitled "Dancer 
Internals".

So basivally, you have:

- The core
- Engines
- the DSL layer
- Plugins

Most of the engines are outside of the core, what the core provides is 
the abstract class real engines must implement.

1: http://advent.perldancer.org/

> 2. I think, Dancer.pm sholud be able to export methods in two ways - all at once (like current ':syntax' tag do), and separately (on demand).
> If I could, I would change current @EXPORT to @EXPORT_OK. Why? When we create request handlers ':syntax' is cool, but when we want to create
> something more complicated it is inconvenient (for example, if I "use Dancer" I can't use (very natural) method names, like "get"). Of course
> I can set all what I need (in most cases config/logger/request/session) as arguments of constructor, but it is not "Dancer" like solution? Of
> course there is third method, I can (for example) use Dancer::SharedData, Dancer::Session, Dancer::Logger and get all what I need in the same
> way like you do in Dancer.pm, but having the same logic in 2 places is... ugly! :-) The best way I thing would be:
>
> "use Dancer qw( config logger ... )".

You're right on this, and we are aware of that. This is one of the 
improvement we have planed for 1.4


> 3. Why Dancer::Request "current instance" is stored in SharedData, and Dancer::Session is not? This are both the same "per request" kind?

Same as the previous one: we'll do some huge refactoring of the 
internals for 1.4, this may change as well. You have to know that we put 
a lot of effort to stabilize the actual version of Dancer into a mature 
and solid release (1.2xxx).

Refactoring is still needed, we're aware of that, but that was more 
important for us to release 1.2 first. Now that it is out, we can start 
focusing on this kind of things.

Expect it to happen in 2011.

> 4. I thing, Dancer ':syntax' should have a&logger method, that returns "current logger" instance. If I want to get it (for example, to pass it as argument somewhere) I have to get it from Dancer::Logger, and this is (once again) not "Dancer" like solution (I think)...

Well, Dancer is a DSL, that's why people like it. debugging a web app is 
of very common use, and I'd rather do in my app "debug", "warning" or 
"error" rather than issuing: "logger->debug"

Basically, that's also why I dared bypassing the Perl culture by 
ignoring @_ and full OO approach. Agian, that's a key-feature for lots 
of people that use Dancer. IT's very expressive because of that specific 
choices.

That's part of Dancer's personality, and we should keep it that way.


> There is a few more things, but first, I want to know your opinion about this four...

You're welcome, I suggest you subscribe to the mailing-list if you have 
more: http://lists.perldancer.org/cgi-bin/listinfo/dancer-users

>
> Of course you allways can say: "wtf. get lost" - this does not change anything, and I will still "use Dancer" ;-)
>
> Once again, "realy cool piece of... code"! Thx

You're welcome, stay tuned with the calendar, that article speaking 
about will detail the things covered in this mail.

Regards,

-- 
Alexis Sukrieh