Any questions?
Perhaps this one: why do you just stick to words and don't
get the meaning. "Don't change" means in this context "don't change them in a way they show up different than now in a HTML editor/viewer". No more questions.
As for the benefits or drawbacks of your system, I don't have any comments as I don't understand how your system glues the disjointed chunks of Perl together.
Simple. I turn the files inside out
outside in, and lo! the disjoint chunks are not longer
disjoint.
You didn't aviod creating a system, you just created one that seemed obvious to you and one that you don't yet see the long-term benefits and gotchas of.
From miniperlmain.c:
/*
* "The Road goes ever on and on, down from the door where it began."
*/
...and wither then? I cannot say.
Most likely I wouldn't adventure anything if seeing
the "long-term benefits and gotchas" were crucial criteria for my actions.
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply]
[d/l] |
Yeah, you didn't get my points in the other thread either.
"Don't change" means in this context "don't change them in a way they show up different than now in a HTML editor/viewer".
and yet
Ah, and don't change those HTML files. It's likely they get revised after the app is finished.
And what good does it do to add only HTML comments when the person who is doing the revising has no idea how to keep those HTML comments so that they actually work with your system? Are you assuming that revisions will be so tiny that your HTML comments will still work?
Most likely I wouldn't adventure anything if seeing the "long-term benefits and gotchas" were crucial criteria for my actions.
Yeah, not even close to my point. *shrug* Sorry you felt I didn't get your points. Sorry it appears that I failed to get my points across. Good luck anyway.
| [reply] |
Yeah, you didn't get my points in the other thread either.
I guess I got your point (sometimes I'm slow and stubborn), and I re-read upon do and require, and now I'm checking the source. I understand that since it is not clearly stated that require does return the last evaluated
expression of an eval'ed file on success it is free to return
any value as long as this value is 'true' in the
perl sense. As for now, require returns the last evaluated
expression, and I deem such behaviour is intended and not by chance. But I think I need require, unless I write a
require-like sub on my own. Would that make more sense? But then, since I'm mimicking AutoLoader also...
And what good does it do to add only HTML comments when the person who is doing the revising has no idea how to keep those HTML comments so that they actually work with your system? Are you assuming that revisions will be so tiny that your HTML comments will still work?
It's a great deal better than adding non-W3C-compliant
stuff which might break design. The person that is doing
the revision just has to leave the comments in, and if
they're broken, I fix them. It's not a great deal moving
some lines around or applying logic for additional fields;
but web design can be a pain if strange [% %] or ;> or
whatever stuff appears in unexpected places, probably
breaking things.
But you may be right, we aren't getting each others
point, happens sometimes. I am puzzled also with this node by chromatic, I simply don't get what he is trying to tell me..
Yeah, not even close to my point. *shrug* Sorry you felt I didn't get your points. Sorry it appears that I failed to get my points across. Good luck anyway.
I'm feeling sorry for this as well. You emphasize system in your post, and that I didn't avoid to create one. I'm turning files ouside in; store them in a perl standard way for the __PACKAGE__ that creates and uses them and make them suitable for use via AutoLoader. If that's a sytem on it's own for you, I haven't any arguments left. I look at the whole stuff as a way to provide templating which adheres closest to perl standards,
and it should fit smoothly everywhere and do it's simple, single chain of tasks as does e.g. Data::Dumper.
Tags/markup/mini-language of the inside stuff of
templates which I turn outside are at that stage of no concern, and in fact any flavour of [%mini.markup.lang%] or
<TMPL_FOO> markup and variable passing implementation
is trivial -- am I getting closer to address your point with that?
sorry again,
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply] |
