Ok, I've tried at length to explain my insanity elsewhere, and bored a lot of people into not listening with walls of text. So I'm going to try and be as concise as possible here, still hopeful to start a code-fire that burns down the whole forest...
ABSTRACTION MAKES ME A HAPPY WEB DESIGNER!!!!
The following is just a suggestion, not working code it might be syntactically wrong, I'm trying to paint you a picture of something beautiful that I want to share very badly.
use abstractor; #there is no real name yet
my $output = abstractor->new();
$output->load_definitions(
# dirpath to definitions dir
);
#or
$output->add_definitions ( { a => 'print "HELLO"',
b => 'print "WORLD"',
c => 'print "!!"' } )
$output->compute("<a></a> <b></b> <c></c>");
HELLO WORLD!!
Can you see what that does? I hope so!! The rabbit hole goes deeper, please bear with my idi0cracy.. I want to give this to you but I don't know how to explain it better than this!
$output->add_definitions ( { a => '$result = "HELLO"',
b => '$result = "$data WORLD"',
c => '$result = "$data!!"' } )
#$data is the string inside the tag so if you have a
#tag <b> which contains the string "HELLO", then $data
#will be equal to "HELLO" when the tag is being computed
print $output->compute("<html>
<head></head>
<body>
<c><b><a></a></b></c>
</body>
</html>");
#the interpreter ignores tags that it does not have #definitions for
Output :
<html>
<head></head>
<body>
HELLO WORLD!!
</body>
</html>
$output->add_definitions ( { a => '$result = "HELLO"' });
print $output->compute("<a></a> <a></a> <a></a>\n");
print $output->compute("<a><a><a></a></a></a>\n");
HELLO HELLO HELLO
HELLO
$output->add_definitions
(
{ a => '$result = "<html>$data</html>"',
b => '$result = "<body>$data</body>"',
c => '$result = "HELLO WORLD!!!"'
});
print $output->compute("<a><b><c></c></b></a>\n");
<code>
Output :
<code>
<html><body>HELLO WORLD!!</body></html>
Does it start to make any sort of sense yet? What I'm talking about here is not a framework, altho I have built a framework out of it (it's too slow using my naive methods)
This abstraction method along with just another couple of quirks makes me able to build very complex sites out of completely reusable code blocks, and the abstract xmlesque code is completely operating system and even implementation language agnostic!
Come on someone out there must get it!
|
Re: RFC : Abstraction Markup
by dHarry (Abbot) on Jun 29, 2011 at 07:43 UTC
|
Ok, I've tried at length to explain my insanity elsewhere, and bored a lot of people into not listening with walls of text.
But were you listening? Maybe they tried to tell you that you reinvented the wheel:)
"Abstraction" is a general SW engineering principle, e.g. design by contract. Like mentioned above, you seemed to have reinvented templates. Take a look at one of the alternatives on cpan and see how it compares to what you did. Then convince me what you did is better.
Cheers
Harry
| [reply] |
Re: RFC : Abstraction Markup
by Anonymous Monk on Jun 29, 2011 at 06:42 UTC
|
Can you see what that does? I hope so!! .... Come on someone out there must get it!
You're describing a templating system called JSP or Java Server Pages
You should study how JSP came about, the problems it tried to fix, the problems it generated, and how Sun tried to fix them , JSTL... sorry, I have no link
You should also study templating systems in general -- there isn't very much new under the sun
See also Mason, Embperl, Template, Text::PSP/Apache::PSP, HTML::FormFu, HTML::Element::Library ...
See also mod_perl: Choosing a Templating System
| [reply] |
Re: RFC : Abstraction Markup
by luis.roca (Deacon) on Jun 30, 2011 at 02:06 UTC
|
"Does it start to make any sort of sense yet? What I'm talking about here is not a framework, altho I have built a framework out of it (it's too slow using my naive methods)
This abstraction method along with just another couple of quirks makes me able to build very complex sites out of completely reusable code blocks, and the abstract xmlesque code is completely operating system and even implementation language agnostic!
Come on someone out there must get it!"
Regardless of how useful/popular this module becomes for others it's
clear you're excited and getting a lot out of the process. That's great. :)
I do however see problems with what you have so far if this
is to be used by content managers, designers etc.
- Having an 'xmlesque' type syntax that is not actually xml or html may
get very confusing very quickly.
- Also, how would I incorporate something like CSS (inline or imported ie: <div style="header"></div>) with your system? By what I've seen so far, I get the sense the code would become pretty unwieldy.
I am admittedly new to Tempalte::Toolkit (currently on page
49 of the 500+ page Perl
Template Toolkit) but it's easy to see how I could send a file to a
client and feel confident they would be able to understand it without much instruction.
Take one of your first examples. I would feel more comfortable sending the following to a client or fellow designer:
[%
a = 'HELLO'
b = 'WORLD'
c = '!!'
%]
<html>
<head></head>
<body>
[% a %] [% b %][% c %]
</body>
</html>
Then to process this simple template and output to a new html page from the command line:
$ tpage hello.tt > hello.html
Creates and writes to hello.html:
<html>
<head></head>
<body>
HELLO WORLD!!
</body>
</html>
You may not be concerned about the same audience I am but consider how confusing looking
at a file filled with html/xml style tags three, six or twelve months
after you write the template would be.
My feeling is that if abstraction is your goal, it's not abstract
enough. Look at Template for a very nice system that achieves abstraction. In contrast, I think it would also be beneficial to look at Text::Template for an anti-templating perspective. The documentation in particular (Check the Philosophy section) is a good description of the template creation process and why it fails many times.
Good luck and keep having fun!
"...the adversities born of well-placed thoughts should be considered mercies rather than misfortunes." — Don Quixote
| [reply]
[d/l]
[select] |
Re: RFC : Abstraction Markup
by metaperl (Curate) on Jul 01, 2011 at 16:42 UTC
|
Well, you are aiming for some separation between the HTML and the data. What you are doing is basically what Paul Lucas' "HTML_Tree" Perl module does. He took it off CPAN becuase another module like that already existed.
From my perspective, you are still putting programming the backseat and HTML in the front-seat. Instead of taking control of the situation and injecting data into the HTML via DOM or one of Perl's many push-style solutions, you are still trying to program the HTML via a simple correspondence table between hash keys and html tags.
So, what you have is putting the power in the middle. Blatant pull-style systems like Mason and TT have a lot of power because they allow programming in HTML. Blatan push-style systems like my own HTML::Seamstress have a lot of power because they prohibit programming in HTML, but require Perl for all programming.
What you have is something with limited programing power from either perspective. Which may be fine, but it might not be. Also see URI Guttman's Template::Simple for another attempt to have automatic templating based on Perl data structures. As well as Petal for Perl's tal-inspired templating.
| [reply] |
Re: RFC : Abstraction Markup
by sundialsvc4 (Abbot) on Jun 30, 2011 at 03:42 UTC
|
Actually, ColdFusion did do something very similar to this ... the pages consist of XML-like tags interspersed with the HTML (which, of course, is also made up of tags).
As far as I could ever figure out about how the thing actually worked, it seemed that it was rather like a over-glorified XSLT of sorts. And, it actually does work... And it’s not “just PHP,” because the runtime engine obviously looks at the document structurally. (The drawback is that eventually you get damn-tired of typing <CFeverything> <CFin> <CFthe> <CFfriggin> <CFworld>, <CFover> <CFand> <CFover> <CFagain>. But, hey, it’s an acquired taste, I guess, and open-source implementations do exist.)
So, your essential idea, while not entirely new (what really is??), was viable enough to have been developed into a still very widely used application-server product.
| |
Re: RFC : Abstraction Markup
by sundialsvc4 (Abbot) on Jul 02, 2011 at 19:40 UTC
|
One consideration which still tends to drive my work towards a “template-driven” perspective is that, very often, it is the presentation to the end-user that most often requires to be “diddled” in order to get the final invoices paid on-time. I like to write apps in which the back-end is mostly responsible for providing the data content, but in which the back-end also provides the presentation ... doling it out, as it were, in small doses, and employing rapidly-customizable templates as the source of the information. I really don’t want to have two programs to deal with at the same time.
I would say, though, that more experienced designers than myself would probably dismiss my approaches as “old school,” and if they did I probably could not deny them.
| |
|
|
Ok, guys I have read and digested (and been grateful for) all of the above comments. I know that from your end the probability that I have created something worth looking at is very low, and that in all likelyhood it appears I have simply reinvented a perfectly good wheel.
Appearances can be deceptive.
Yes there are real similarities between what I have and the systems mentioned above, but none of those do what my system does, and I have looked at them.
All I can say is that I feel immensely constrained when working with any other language, and I would love to find an existing wheel which does exactly as my wheel does, but it doesn't seem to exist.
Now from what I have given above it is difficult to explain why that is, because I haven't given you the whole story yet it was just an inroad, an attempt to start explaining something I don't know how to explain, and yet as a strong believer in the opensource principle, dearly wish to share with the world.
The only solution I can see right now, is to continue trying to explain what I have, and hope that I don't bore the pants off you guys before the picture becomes clear and you can objectively judge the merits of thing.
Ok, if your still with me, I will elaborate further...
The definitions of the tags are usually stored in a plugins folder, one file for each tag the filename corresponding to the tag name and containing the code to run for that tag.
I have about 50 definitions in all which cover just about everything I can think of, and typically as I move from project to project I don't make any changes to the core engine or the tag set.
So when I start a new project I simply build (or copy) an existing barebones template file accross, and then start building the pages. Thus I can have something up and running in minutes.
My implementation handles all the database level shash etc, leaving me free to simply design the tables, queries and UI. for a typical project I may not have to write any plugins or code at all, since all the functions needed are covered by the existing plugins and the unique method I found to stack them together in many different ways.
It is this "unique method" which is the bit I most want to share, since the rest of the framework I have built around it and indeed the plugins are just icing on the proverbial cake, and moreover it's a cake that needs refinement to improve efficiency.
I would LOVE it, if Template Toolkit or similar allowed me to use the "unique method", but it doesn't nor does any other system I can find.
My schema has very simple set of rules and 3 types of tag delimiters, which indicate process priority over child tags. This may seem arbitary but once you see the reasons for it, it becomes very useful.
Rule 1 : Child tags are computed prior to parent tags.
Rule 2 : The $result of the computation of a child tag, becomes the $data of the parent tag.
Rule 3 : Tags delimited by ( ) type brackets, are computed
prior to their children unless the child tags are also of the type ( ).
Rule 4 : Tags delimited by [ ] type brackets, are computed last.
Rule 5 : The system only computes tags which it recognises and are syntactically valid, whilst ignoring everything else.
So with those rules in mind consider this action page;
listing of /actions/default/main.aXML
<table width="50%">
(DB)
<query>
SELECT * FROM latestnews;
</query>
<mask>
<tr>
<td>
<d>news_title</d>
</td>
<td>
<d>news_headline</d>
</td>
<td>[link action="readnews"
newsitem="<d>news_id</d>"
]Read More...[/link]
</td>
</tr>
</mask>
(/DB)
</table>
Because the DB tag is of type ( ), it is computed prior to its child tags, and produces a list of news items and links.
Because the link tag is of type [ ], the links are processed last to become standard hyperlinks to the news items.
It's not a framework, I am not trying to plug a replacement to template toolkit etc, I am just trying to show you the "unique method" I found and why it saves me huge amounts of time and effort. In the length of time it has taken me to tap up this essay, I could of built a whole news system complete with validation and presentation etc, because I've already done the grunt work on previous jobs and now I can just mix and match the components using the simple rules to create endless variations.
| [reply]
[d/l]
[select] |
|
|
So with those rules in mind consider this action page;
What you have described looks like basic Template::Plugin::DBI or HTML::Mason, or AxKit... you created a standard set of templates/plugins/components/filters... for common tasks
I am just trying to show you the "unique method" I found and why it saves me huge amounts of time and effort....
Perhaps the reason it saves you time and effort is because you, the designer and implementor, know it well -- describes majority of software -- code-fire is hard to start , it requires lucky timing :)
| [reply] |
|
|
I don't understand; what is the handler for the DB tag actually passed? The raw text contained in it, <query>, etc. and all?
| [reply]
[d/l] |
|
|
|
|
|
|
|
