[Dancer-users] about Dancer
Alexis Sukrieh
sukria at sukria.net
Tue Dec 7 12:30:52 CET 2010
[ 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
More information about the Dancer-users
mailing list