On Frameworks, RoR & PHP
Moderator: General Moderators
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Personally I feel there is a slight distinction between web application development and web site development.
Web sites are typically changed (in terms of markup as well as content) more than a web application (unless you allow re-branding).
Saying that, how do you allow your clients to change the markup if it's generated on the fly via View or any method, other than templates?
Web sites are typically changed (in terms of markup as well as content) more than a web application (unless you allow re-branding).
Saying that, how do you allow your clients to change the markup if it's generated on the fly via View or any method, other than templates?
With the generator, I get 100% markup, all of the time, and time spent developing that markup is next to nothing, compared to templating where I have to organise my templates, even in Hierarchical View systems, I cannot render a component that updates the <head> content if I am rendering <body>. Full generators handle all of that for me, I can add a header, or a body attribute, or even change doctype at any stage of the rendering process and it will still come out 100% valid - not so with Templates, and with difficulty on Hierarchical View's. I can also, at the flick of a switch, change the markup completely if need be, to anything. Commonly swapping between HTML and XML for data feeds and normal views. No "duplication" development creating a view for both, I simply develop it once, and that's all I need.arborint wrote:This does not sound much different from Input or Form Controllers. Can you give a code example, maybe a login form...Jenk wrote:callbacks are simply a state of execution on hold until it is called upon.
In Seaside, this allows me to generate a form, and for each input I can assign a callback. Example textinput callback would simply be to assign the value of the input to a variable, for later use - usually in the callback I assign to the form (ergo, the submit action.) where I then use the input's for processing.
An anchor callback can be anything, but usually to display a different component (ergo a different page.)
I don't see the advantage of this over hierarchical Views. I can attach anything with a render() method to any element in the tree. It could be a template, a View, a HTML generator, etc. It all gets assembled by the response. If I needed to build everything out of HTML generators I could, or all out of templates as well. Usually it is a mix though.Jenk wrote:Programatically generated output has huge advantages. I can generate a view with nothing but a simple <h1> block from one component, but I can also create a view that has dozens of components (which are seperate objects) and still be safe in the knowledge that the final output will still be valid. I could also render any of those mixed-and-matched components individually, and still create valid markup.You claim "huge advantages" but the main thing you like is "valid markup 100% of the time." In the whole scope of a project that is not that important to me and also not something I have a problem achieving on releases. Typically the stuff with sophisticated markup is the layout that gets defined when the site is designed and does not get changes until the site is redesigned. The content is usually very simple layout-wise, yet that is what changes.Jenk wrote:I can mix and match any component with the generator and it will render valid markup 100% of the time. No matter which order I render them in. This is not the case in templates. I have to ensure I 'include' sub-templates in their correct places and so forth.
If I do try to render malformed markup, the generator will not let me. Templating will allow me to make as many mistakes as I like.
You're clearly closed minded about it all anyway. I'm expecting you to post "We've already covered generators" and fail to respond with a reasoned agrument.
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
Oh wow. Please show the code that would do that.I can add a header, or a body attribute, or even change doctype at any stage of the rendering process and it will still come out 100% valid
I don't see the advantage of this over hierarchical Views. I can attach anything with a render() method to any element in the tree. It could be a template, a View, a HTML generator, etc. It all gets assembled by the response. If I needed to build everything out of HTML generators I could, or all out of templates as well. Usually it is a mix though.
I've tried to approach site development in the same as application development and templates and ended up with a headache. The only way I could make it work was to embrace generated mark-up and templates for what they are.Personally I feel there is a slight distinction between web application development and web site development.
Generated mark-up gives you a lot of programmatic control, abstracts a lot of logic and objectifies HTML making is testable and polymorphic. This comes at the expense of complication and the fact that you aren't working with HTML itself. One has to mentally convert the pure PHP into HTML. Simply put if you don't need to reuse it or it doesn't have complex logic you shouldn't use generated mark-up it should be for mark-up that represents functionality such as forms, database output, pagination controls etc.
Templates are mainly static HTML with bits of injected PHP. These PHP injections can very easily be mark-up generating objects and likewise a template can, and should, be objectified so they can pretend to be a mark-up generating object. XSLT is amazing because it basically allows you to do both of these simultaneously using a single syntax. Trouble is it is sorely lacking in other areas, it could really do with a decent standardized interface to a more conventional language like ECMAScript or PHP. Anyway, I digress.
Here's an example of what I'm suggesting. Here we have standard template, the navigator object with is something in between and the call to $this->content->render() that could be either a template or generated markup.
Code: Select all
<?php function prepend($str, $prependage)
{
if (strlen($str)) {
return $prependage . $str;
}
}
$this->setEscape(new HtmlEscaping()); ?>
<!-- invalid mark-up for brevity -->
<html>
<head>
<title>MySite<?php echo prepend($this->pageTitle, ' - ') ?></title>
<?php foreach ($this->css as $css): ?>
<link rel="stylesheet" src="<?php echo $css ?>" />
<?php endforeach; ?>
</head>
<body>
<div id="top">
<h1><?php echo $this->pageTitle ?></h1>
<?php
// This object is runs a bit of XPath over some HTML to find a match
// and than uses a manipulator to make a modification to that match.
// The DOMManip_AddClass class is being used to make the modification
// and will add the class="active" attribute to the current list item.
$nav = new Navigator();
$nav->setContent('<ul id="nav">
<li>foo</li>
<li>bar</li>
<li>zim</li>
</ul>');
$nav->setSelection("ul/li[. = '{$this->pageTitleAsNavItem}']");
// This could easily just be a callback
$nav->setManipulator(new DOMManip_AddClass('active'));
echo $nav->render();
?>
</div>
<div id="content">
<?php echo $this->content->render() ?>
</div>
<div id="bottom">
<cite>© me!</cite>
</div>
</body>
</html>-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
I accomplish all that using templates and views.Jenk wrote: Full generators handle all of that for me, I can add a header, or a body attribute, or even change doctype at any stage of the rendering process and it will still come out 100% valid - not so with Templates, and with difficulty on Hierarchical View's. I can also, at the flick of a switch, change the markup completely if need be, to anything. Commonly swapping between HTML and XML for data feeds and normal views. No "duplication" development creating a view for both, I simply develop it once, and that's all I need.
You're clearly closed minded about it all anyway. I'm expecting you to post "We've already covered generators" and fail to respond with a reasoned agrument.
I am curious. How is your GUI stored if not in native HTML? How do you build the interface in the first place? Surely you don't start programming your HTML builder object with functions like: addHead(), insertDiv()
Then reuse that class in other projects? What happens if the client wants a button added, a link removed, etc. Then next week, they request those same features be re-added and then two days later, they revert back to the original idea? As an example, changing your HtmlBuilder class by calling or removing functions would be savage.
Cheers
In Smalltalk, as I don't use PHP anymore:
That's the method for rendering the content, which is the "main" method of the component. The component also has methods for updating the root, such as adding sections to a url:
To update any headers, my component can override the #updateRoot: method:
Now in combination with other components for any view, I am still guaranteed valid markup. Templates will not do this. I would need to make sure my templates have hand-written valid markup, and are explicitly ordered correctly so that I don't get duplicated <head> tags, for example.
The difference between templates and a generator like that of Seaside would be the templates are very static, you must 'call' them in the correct orders and ensure you don't have any out of place tags. The generator looks at everything that is going to be rendered, then calls upon the various methods to ensure that nothing is out of place.
The other major difference, is in a template, if I make a mistake, it will still render. In the generator above, it will not.
Code: Select all
renderContentOn: html
html div id: 'menu'; with: [
html unorderedList with: [
self menuItems do: [:each |
html listItem with: [html text: each]]]].Code: Select all
updateUrl: aUrl
aUrl addToPath: 'something'Code: Select all
updateRoot: aRoot
aRoot title: aRoot title, 'This is added to the page title'.
aRoot bodyAttributes at: 'onload' put: 'someJSFunction()'.
aRoot headElements add: (WAHtmlElement named: #meta attributes: {'NAME' -> 'keywords'. 'CONTENT' -> 'some keywords'})The difference between templates and a generator like that of Seaside would be the templates are very static, you must 'call' them in the correct orders and ensure you don't have any out of place tags. The generator looks at everything that is going to be rendered, then calls upon the various methods to ensure that nothing is out of place.
The other major difference, is in a template, if I make a mistake, it will still render. In the generator above, it will not.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
By bulletproof you mean what exactly?Jenk wrote:No you don't. Well, you do, but not in the bullet proof way a generator does.Hockey wrote:I accomplish all that using templates and views.
I would have to see an example of how you use a "generator" to build bullet proof html.
The only generator I am aware of in popluar use is FORM builders, where you build the FORM programatically using API and with a single function you get the entire FORM output. You really loose a lot of control over the layout of your FORMs that way and an application isn't any different.
Are you blind?
viewtopic.php?p=396500#396500
viewtopic.php?p=396500#396500
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
No, but you broke the rules in double posting. So I immediately assumed the last was the last and only post of yours.Jenk wrote:Are you blind?
viewtopic.php?p=396500#396500
Admittedly I was lost looking at your smalltalk examples...Jenk wrote:Now in combination with other components for any view, I am still guaranteed valid markup. Templates will not do this. I would need to make sure my templates have hand-written valid markup, and are explicitly ordered correctly so that I don't get duplicated <head> tags, for example.
The difference between templates and a generator like that of Seaside would be the templates are very static, you must 'call' them in the correct orders and ensure you don't have any out of place tags. The generator looks at everything that is going to be rendered, then calls upon the various methods to ensure that nothing is out of place.
The other major difference, is in a template, if I make a mistake, it will still render. In the generator above, it will not.
1) Granted, templates have to be hand-written to guarantee validity. But, when you mock a design and make sure it's valid before you start making it dynamic, that is already taken care of.
2) As for duplicated <head> tags. I'm doing it differently then, cause that has never been a problem. Actually in my latest incarnation it's technically impossible.
3) If the markup isn't valid your generator stops? Why? Personally I'd rather show the HTML as is (in hopes the user agent rendered properly) and send myself an email notifying me there somehow is invalidity crept in.
Last edited by alex.barylski on Sun Jul 01, 2007 9:07 pm, edited 1 time in total.
If you are going to nitpick about forum rules, make sure you read them yourself first:

mine are not identical posts3. Do not make multiple, identical posts. This is viewed as spam and will be deleted.
If there is a mistake, my application will not run - forcing me to fix it. The semantics are catered for by the generator, the only thing left is for me to develop using smalltalk syntax. If I make a mistake, it would be like missing out a ';' in php - I would receive the equivalent of a parse error.Hockey wrote: Admittedly I was lost looking at your smalltalk examples...
1) Granted, templates have to be hand-written to guarantee validity. But, when you mock a design and make sure it's valid before you start making it dynamic, that is already taken care of.
2) As for duplicated <head> tags. I'm doing it differently then, cause that has never been a problem. Actually in my latest incarnation it's technically impossible.
3) If the markup isn't valid your generator stops? Why? Personally I'd rather show the HTML as is (in hopes the user agent rendered properly) and send myself an email notifying me there somehow is invalidity crept in.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Again Jenk, I don't see the advantage other than your "100% correct markup". In the system I use, any view can also update the <head> <doctype> or anything else you want. That is because View and Response classes share base code. So again, I could do all generated output if I wanted to -- I just currently don't want to. Turning over the editing of templates to designers and site content maintainers frees me from that drudgery. However you have piqued my interest in doing more programmatic stuff. I have always like the idea of Views being able to do everything they need.
For me the template vs generated conversation is much less interesting that learning about callback based systems. Does anyone have a simple PHP example of a callback system or a sample app that uses a callback based PHP framework.
For me the template vs generated conversation is much less interesting that learning about callback based systems. Does anyone have a simple PHP example of a callback system or a sample app that uses a callback based PHP framework.
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
I can easily configure my framework to throw an exception on invalid markup, but i odn't need to as I can also configure the framework to 110% gaurantee me that the output is valid according to whatever DTD I set it to. I chose not to enable this feature as it's heavy on CPU clocks but the fact is, I could if I wanted to and I do during debugging, but disable it during release.Jenk wrote:If you are going to nitpick about forum rules, make sure you read them yourself first:mine are not identical posts3. Do not make multiple, identical posts. This is viewed as spam and will be deleted.
If there is a mistake, my application will not run - forcing me to fix it. The semantics are catered for by the generator, the only thing left is for me to develop using smalltalk syntax. If I make a mistake, it would be like missing out a ';' in php - I would receive the equivalent of a parse error.Hockey wrote: Admittedly I was lost looking at your smalltalk examples...
1) Granted, templates have to be hand-written to guarantee validity. But, when you mock a design and make sure it's valid before you start making it dynamic, that is already taken care of.
2) As for duplicated <head> tags. I'm doing it differently then, cause that has never been a problem. Actually in my latest incarnation it's technically impossible.
3) If the markup isn't valid your generator stops? Why? Personally I'd rather show the HTML as is (in hopes the user agent rendered properly) and send myself an email notifying me there somehow is invalidity crept in.
- kyberfabrikken
- Forum Commoner
- Posts: 84
- Joined: Tue Jul 20, 2004 10:27 am
PRADO is event driven. I never used the framework, so I'm not sure about the details, but the front page of http://www.xisc.com should give a hint.arborint wrote:For me the template vs generated conversation is much less interesting that learning about callback based systems. Does anyone have a simple PHP example of a callback system or a sample app that uses a callback based PHP framework.
Because of PHP's stateless nature, you can't use continuations, which - if I'm not mistaken - is the way Seaside works? A continuation is even more powerful way of preserving state than the way application servers such as JSP or .NET does it. With a continuation, you not only preserve data, but also the program pointer/stack frame. Smalltalk can be a bit alien to developers, who primarily work with C-like languages. For an idea about, what a continuation is, have a look at cocoon:
http://cocoon.apache.org/2.1/userdocs/f ... tions.html
Correct, Seaside uses Continuations. However, the talk on the mailing list is that they are currently used over zealously and in future versions they will be used less as at the moment they are currently used where it is not necessary; i.e. only callbacks need them.
To implement something similar to Continuations in PHP you would need to snapshot every object into session data (or something more persistent) and then restore that data when it is requested.
Example of a callback in php (from Phaux:) http://phaux.googlecode.com/svn/trunk/C ... veTest.php
To implement something similar to Continuations in PHP you would need to snapshot every object into session data (or something more persistent) and then restore that data when it is requested.
If someone else is making all your templates, then there's only one real advantage, and that is the chance of human error in your markup being next to zero. There's also the small advantage that you don't actually need to have much knowledge of the markup; only the language you are developing in.aborint wrote:Again Jenk, I don't see the advantage other than your "100% correct markup". In the system I use, any view can also update the <head> <doctype> or anything else you want. That is because View and Response classes share base code. So again, I could do all generated output if I wanted to -- I just currently don't want to. Turning over the editing of templates to designers and site content maintainers frees me from that drudgery. However you have piqued my interest in doing more programmatic stuff. I have always like the idea of Views being able to do everything they need.
For me the template vs generated conversation is much less interesting that learning about callback based systems. Does anyone have a simple PHP example of a callback system or a sample app that uses a callback based PHP framework.
Example of a callback in php (from Phaux:) http://phaux.googlecode.com/svn/trunk/C ... veTest.php