Hi Jon,
in this mail are two real-world problems using Mason2. And i'm happy
than not only me have this problems. Jon, please, can you "somewhat"
address them? :) :)
> 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.
IMO, most of user will write his separated applications for different
things, what are usually need for one common site, like: some simple
blog, (not everybody want use wordpress or som other "full-blown" blog
solution), eshop, the "main site" and so on.
All of these apps can be an independent, self-contained PSGI apps.
But (of course), the users want "mount" theese mini apps in the
app.psgi. So (as in one older post) want to do:
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.
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.
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.
IMO, Mason2 compiler should accept the <&| component &> content </&>
and the compiler should translate it into $.CompCall....
automagically, so the old component syntax will remain and Mason2 will
translate it into his internal filter-call.
Could you please show, how I should rewrite the following nice and
clear example into Mason2?
<&| /jq/tabs.mc &>
<&| /jq/tabs.mc:tab &>
content of the 1st tab
</&>
<&| /jq/tabs.mc:tab &>
content of the 2nd tab
</&>
</&>
Can The Fellowship of the Mason2 hoping for the "return of the king"
(read: old syntax for calling components with content?) or we will
stuck forever with calling components <&| .. &>' as a filters <%
$.CompCall( ... { %> ? (Two towers) ;)
Ps:
Roman,
Jon forgot mention in his answer to your question - the "CompCall"
filter (see:
http://search.cpan.org/~jswartz/Mason-2.20/lib/Mason/Filters/Standard.pm#CompCall
) what is the (messy) Mason2 replacement for calling "components with
content".
ak.
> Subject: Re: [Mason] Mason2: Filter (component with content) syntax
> To: Roman Daniel <roman.dan...@davosro.cz>
> Hi Roman,
>
> There are two separate issues here: (1) where are filters defined, and (2)
> how are they applied.
>
> 1. In Mason 2 filters are defined by methods, rather than by components. This
> makes sense for a large variety of filters that don't output content of their
> own but simply process their incoming content in some way. e.g. an uppercase
> filter:
>
> method Upper () {
> return sub { uc($_[0]) }
> }
>
> However, it is still possible to define a filter out of a piece of component,
> e.g. your example of a Javascript filter that wraps its input with a script
> tag:
>
> <%filter Javascript>
> <script type="javascript">
> <% $yield->() %>
> </script>
> </%filter>
>
> 2. As you know the main syntax for applying filters is with perl lines, e.g.
>
> % $.Upper {{
> some text that will be uppercased
> % }}
>
> I chose this because it seemed like a similar situation to other
> brace-delimited control structures: if, for, while, etc.
>
> However, there is an another syntax for applying filters that is still
> supported, though currently not documented:
>
> <% $.Upper { %> some text that will be uppercased <% } %>
>
> I think this is more like the "inline markup" you are looking for. It is too
> much tag soup for me, but if people like it for certain situations then we
> could leave it officially supported and document it.
>
> Jon
>
> On May 16, 2012, at 7:17 AM, Roman Daniel wrote:
>
>> Hi,
>>
>> I used Mason1 quite a lot and recently switched to Mason2 for new projects.
>>
>> I wonder what was reason for leaving the component with content syntax
>> in favour of "perl" lines, i.e.
>>
>> why
>>
>> % $.js {{
>> % }}
>>
>> instead of
>>
>> <&| $.js &>
>> </&>
------------------------------------------------------------------------------
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
