Hi,
On Mon, Jul 16, 2012 at 1:34 PM, A Kobame <kobam...@gmail.com> wrote:
>> If you have several different sites, I think it is cleanest to have a
>> separate Poet
>> environment for each of them, with its own app.psgi and Mason component root.
>> You can run them on different ports and have an nginx or similar running in
>> front
>> that maps domain names to different ports. This is what I do on my own
>> servers.
>
> Jon, this is simply not true.
Maybe its not true for you, but it true for some. I myself have a app
that shares 99% of its logic between two sites, two skins if you will.
I run them on separate processes. It makes sense to me and it folds
nicely into the "one site, one system, one process" mentality I have
at $work.
I'm not saying that having the ability to run multiple Poet apps in
the same process isn't a good thing, I just saying that:
1) the current workaround is good enough for now;
2) future Poet version might include this functionality if/when a
clean way is found to do it: I believe there is a message around here
from Jon saying that he would consider a patch for an option to enable
such behavior, I can't find it at the moment though.
> builder {
> enable 'Session';
> mount "/blog" => builder {
> enable 'Static'.... #static files for blog
> $Mason2Blog...
> };
> mount "/eshop" => builder {
> enable 'Static'... #static file for eshop
> $Mason2Eshop...
> };
> $default_Mason2_website_app;
> }
>
> and so on, maybe with different middlewares, but (probably) with one
> common Session middleware..., for some "mounts" want use
> auth-middlewares and so on...
>
> Yes, here is an workaround using reverse proxy and run the apps at
> separate ports, but this is complicated. And you can't have an common
> Session middleware for all apps.
Of course you can have a common middleware and a common session
between all apps. They don't need to share a process space to have
those, just the same configuration for the middlewares. Given that
most of them use a cookie to keep track of stuff, and all your apps
would share the same hostname, it would just work.
> Poet really should support the BASIC psgi behaviors like - app
> mounting. This is one of REAL problem - against using Poet in
> production and trying using only plain Mason2. Poet is simply not
> ready for production yet - or it is ready only for mini-apps, not for
> real-world solutions.
I strongly disagree. Poet is very much ready for production, I've been
running about 5 $work sites on Poet for the past months without a
problem.
I do agree that some scenarios are not supported by Poet yet, and
those scenarios are important to some users, but that doesn't mean its
not ready for production. It means its not ready so solve those users
problems.
Having said that, there are a couple of problems standing in the way
of multiple Poet app in the same process. Poet uses singletons in a
couple of places and uses the app class name as key for a lot of other
stuff. Its also not easy to create a Poet app, with possible several
components subclassed, and then subclass that app to fit separate
sites.
I could use this last bit: create a single Poet app with all my logic,
and then subclass it to skin the site or overload specific parts. I've
toyed with the idea a bit but I haven't had nothing that would work
yet. As soon as I have it, I'll send it here for RFC.
I don't know if Jon will work on this. AFAIK he doesn't need this
particular functionality so I guess he will focus on stuff more
important to him.
> The second problem is the "components with content". In the Mason2 the
> "filters" and "componenets with content" is merged to "filters".
>
> It casusing problems. Why someone must call the "component with
> content" as a filter like:
> % $.CompCall ('list_items.mi', items => \@items) {{
> <li><% $_[0] %></li>
> % }}
>
> Components should be called with '&', so the old syntax <&| component
> &> was </&> nice and consistent. I have many-many (Mason1) components
> what i calling with content. Now when trying move the app to Mason2
> need rewrite all calls to illogical filter calls.
I never used neither components with content with Mason1, and I very
very rarely use filters. I don't particularly like the concept.
But from afar it strikes me that both have the same idea: call
component X with associated content.
So, and again please remember that I'm not a user of either, it seems
to me that they are in fact very similar, and therefore having the
same syntax will simplify things.
Just my €.01, I'm probably missing something obvious.
> IMO, Mason2 compiler should accept the <&| component &> content </&>
> and the compiler should translate it into $.CompCall....
Oh, are you asking just for the syntax sugar then?
Have you looked into subclassing Compiler to add this yourself? Maybe
it is simple and then you could provide a patch...
Best regards,
--
Pedro Melo
@pedromelo
http://www.simplicidade.org/
http://about.me/melo
xmpp:m...@simplicidade.org
mailto:m...@simplicidade.org
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mason-users mailing list
Mason-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mason-users
