Re: Questions about variable propagation and custom component types

On Sun, Sep 07, 2014 at 01:09:21AM +0200, Seb wrote:
> =

> Hi Ladislav,
> =

> =

> > 1) How do I propagate a variable Up the component tree? The use case is =

> > simple: I have Base.mc, which defines most of the page layout, and anot=
her =

> > one, let's say it's foo.mc, which wants to add to the title. I could =

> > probably find a way to hack it by studying the generated class files, b=
ut =

> > surely, there must be a simpler way.
> =

> If this example, perhaps the best option would be <%attr> if the title ca=
n be =

> a fixed string, or <%method> if your component needs to compute the title.

I'll try it, thanks!

> =

> > 2) How do I create custom component type? I've noticed I can add custom
> > suffixed, but seen no way to declare component it self. I've found that=
 pure
> > perl components are a bit hacky, since they seem to only append the =

> > '<%class>'
> > and '</%class>' and are hacked inside the Interp and Compiler.
> > I am thinking of making the same thing, in the end, I just want to see =
the =

> > content before it's modified and filter some stuff in and out. I wonder=
 if =

> > there is a clean way to do it,
> =

> I'm not sure you need a custom component type for modifying a plain text =
file. =

> The obvious option would be to use a textarea (that's what Wikipedia uses=
). If =

> your user is supposed to use a text editor, then maybe he could upload th=
e =

> file afterwards. Am I missing something?

Yes, you are. I want the text file to be a Mason component file, that can d=
o all =

the things and moreover is formated in the right way, so I can generate som=
e =

metadata for it and preprocess the contents by markdown (and if used proper=
ly, =

the markdown will leave Mason instructions intact, so they can be evaluated =

later in the process).

The plain text editor should be something like 'vim', no web based editing.=
..

> =

> > Here, you can see another challenge, and that is indexing of *.pp's, so=
 they =

> > can appear somewhere automatically (and I won't have to call File::Find=
 or =

> > something else each time I want the list), but this is the easiest part.
> =

> If the list of files is not dynamically generated, then you'll want to co=
mpute =

> it once (using 'find', for example) and store the result. You can then =

> dynamically read the stored file, in case you update it by hand or by cro=
ntab, =

> or you can hardcode its contents in the component that allows your user t=
o =

> navigate it. A medium solution would be to use an expirable cache.
> =

> =

> Best regards,
> Seb.

-- =

S pozdravem Ladislav L=E1ska                          <[email protected]=
z>
Katedra Aplikovan=E9 Matematiky, MFF UK               tel.: +420 739 464 167

---------------------------------------------------------------------------=
---
Slashdot TV.  =

Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/