The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

We've also been through your generalization that .NET is just a templating engine a thousand times, disproven it a thousand times, and you continue to repeat it. You're like some PHP version of Colin Powell or something.

Once again, you list addons for PHP which will allow you to do .NET things, while criticizing those same things.

Getting back to your above example, simply having the Repeater control there would allow you to enumerate (in your presentational or business logic, depending on your degrees of separation) everything to be repeated.

Perhaps an example of completely HTML, presentational, logical and business separation (nevermind modularization among all of these) is in order.

Attached is our production level client, multi-server, website tool which we're still developing. It should give you a little taste for what's possible. We haven't implemented some of the newer features, management or degrees of separation in this released code (it's v1, we're releasing 1.2 soon).

Feel free to pick apart, but you'll find it runs fast, takes nearly 0 server resources and beats all the competition. I'd suggest not distributing this, but feel free to use this original version for evaluation purposes.

Easy now J - I'm general interested in the way .NET parses it's templates.

But first I know you get excited about this but if you read carefully, every time I mention .NET and templates, in this post or in the past, I'm very careful to say that it's ASP.NET which is the templating language. I absolutely never say that .NET itself is a templating language - .NET is a framework for executing applications which I understand perfectly.

Please read this post carefully - what I'm saying is ASP.NET is a templating language. It's markup refers to classes and objects. We write a template HTML page and embed ASP.NET tags in it. Conceptually ASP.NET is similar to Smarty but better implemented. It has it's own syntax. Do I need to put ASP.NET in bold again to make it clear I perfectly understand the difference and have done for a long while now.

Anyway - sorry - this wasn't about anything for or against .NET or to annoy anyone - I'm interested in understanding how the ASP.NET syntax related to underlying classes in the most abstract OOP terms.

From what you're saying seems to make the repeater, for example, is either an interface class which my fictional ArticlesList class has to implement in some form or ArticlesList must be an instance of the Repeater class.

The example I gave was attempting to follow the MSDN repeater example - if this violates the principle of seperation, how is it done right?

Fair enough, and if that's what you meant (or said), I'm sorry Feel free to ignore that bit of my post.

If you'd like as close to "best case" as I can find, feel free to download the above applications. The documentation for installation is in there as well

Ideally, the MSDN example would simply place the one ASP.NET control on the page, and then do all the looping/repeating in the code-behind page, to separate the HTML from all logic (except the placement). This gives designers the freedom to do what they need to do (most GUI programs will simply display it as an unknown element).

Behind-the-scenes, you would then separate your presentational logic from your business logic. The example you gave obviously doesn't have any business logic, as it's all presentational, but you could easily bind the list through your DB abstraction layer to an area of your application to create that.

I mean, even within presentational logic, our application separates the template, and core look and feel from the general presentational logic.

Each of these can be completely separated (in reality, you could install several copies of the Mail Server in a distributed environment and it would work fine, so there are even greater degrees of separation (for instance, you'd never instantiate a class directly) than I could graph, but some of the documetnation in that ZIP should help

Still the advocate of MVC and XML/XSLT, when you have a project written in ASPX templates and you need to do a code change on the fly, you end up with a problem. When you deal with XML data bourne off of a class data container, you have no worries about code changes, which means everything is truely separate. The XSLT does the dirty work of making the data which is already processed pretty any way you like it. Perhaps a PDF... or a WML page for the browser or if you fancy "shadowing"(the very bad practice of fooling spiders with extra keyword content specialized just for them) you can do that if you detect the browser could be a spider.

I will look into serialization classes where you can shove your finished data into a class, then drop the object into XML format. I don't think PHP is advanced enough for something like that though, guess it might be back to the drawing board for me.

Harry, interesting post, as usual. But where you say that CSS is a 3rd generation templating aproach or something, your completely losing me. CSS is just for formatting things, how has this anything to do with the template / separation of logic discussion?

Erm, this whole "div" stuff is nothing esoteric, it's a reality. Everybody can use it to layout his pages. It should be noted that it is not allowed to use "ids" more than once. Instead you would use "class". So, even today you can do something like this:
<tr class="articleRow">. I'm doing that everyday, and it works. Besides, if you meant to put these elements into columns, you probably wouldn't use divs, because they're block level elements and as such usually take up at leat one row, unless you specify otherwise. For tabular data it still makes sense to use tables, by the way.

But still i don't really see what this has to do with your first two examples. As there's no presentational logic in there at all, I think basically your 3rd example means that we preapare our pages fully, e.g. with widgets, and output them. Then we won't need a template system at all. Fine. But CSS has nothing to do with this, as far as I can see... It makes no difference if you use CSS here or not, the basic approach would be the same. It's just that with CSS the output would be nicely formatted.

Please correct me if I'm wrong, but I really couldn't leave this uncommented.

But still i don't really see what this has to do with your first two examples. As there's no presentational logic in there at all, I think basically your 3rd example means that we preapare our pages fully, e.g. with widgets, and output them. Then we won't need a template system at all. Fine. But CSS has nothing to do with this, as far as I can see... It makes no difference if you use CSS here or not, the basic approach would be the same. It's just that with CSS the output would be nicely formatted.

The problem with all discussions of templates is there are really two issues being discussed;

1 - Seperation or presentation logic from application logic
2 - How to make life easy for designers (or how to make it possible for developers and designers to work together).

I should have emphasized this more strongly and been more careful but the "three generations" I was talking about were primarily from the perspective of solving the second problem - how to make life easy for developers. I got sidetracked by ASP.NET and eZ publish along the way though.

Originally Posted by HarryF

Personally like the article - makes the point about seperation of presentation logic from application logic well which is, IMO, a different problem to providing a "designer friendly" mechanism for customizing the look and feel of a site.
The presentation logic is usually not completely the realm of a designer to deal; in fact think it's mainly the job of the developer to decide what happens there. The problem is there isn't a clear divide between who does what and what each should be expected to know.
I think there are effectively three generations of approach solving this;

CSS (should) have nothing to do with seperation of presentation logic from application logic - it's purely a mechanism for controlling look and feel which is ideal for designers.

Having said that, when you starting combining CSS with JavaScript or if you consider CSS markup like;

Code:

div.hidden {
display: none;
}

We're back to designers controlling presentation logic again, which blurs the division of labor between them and the developer again.

Erm, this whole "div" stuff is nothing esoteric, it's a reality.

I know but to to do everything with CSS - i.e. all layout, position etc. without any reliance on HTML's in build features isn't quite there yet - in fact the guilty browser is Internet Explorer. But you're right - we're almost there.

As to XSL; well yes and no - consider this - as a developer building a web app, instead of providing discrete "views" as XML you could (at least with a fairly simple content management system) dump one giant XML document containing all the content available on your site and leave it to XSL to break up into "views" - that means XSL blurs the boundary between designer and developer again. Also I think XSL is a tough technology to work with, if you're doing anything more than basic transformations.

Having said that though, CSS isn't an XML based standard, in the same way as DTDs.

Using XML data and XSL to format it would be nice, but what browsers actually support it? I think only IE5.5+ and Gecko based browsers.

I can't remember the project but someone told me once they'd done a PHP XSL parser which first checks to see if the browser has native XSL support and if so, simply dumps the XSL doc and XML on the browser to deal with - if not it uses Sablotron to perform the transformation. If I remember right the project is (somewhere) on Sourceforge

If you look at the source of the page, it remains the same. Clicking on one of the design links alters only the stylesheet used and the output looks completely different.

Basically a developer simply needs to output a page in which every element is well enough described (e.g. with an id or class attribute) for the designer to be able to control it's position, look and feel with CSS. Notice how on some pages the menu is on the right hand side and on others the left?

Basically designers can now be removed from the decision making process of how the presentation logic works.

In terms of technology, it's quite easy, and many sites do it (learn how at www.alistapart.com, they have several articles on the subject).

That said, CSS transformations have their pluses and minuses as well, and I think rank up there with "one of the options", as opposed to the epitome (the way it sounded like Harry was proposing this, at least to me)... Perhaps he's proposing something which doesn't exist yet?

Yes, CSS Positioning can be a real headache, and sometimes you have to sacrifice some ideas in order to achieve best browser compatibility, but once you've fixed all that, things couldn't be easier. You get really clean and maintainable HTML code. For instance, recently I did the CSS based implementation of the new design for www.eocene.net. The menu looks and behaves like "buttons", but in the HTML all you have is a list with links. Everything else is done via CSS. But you still have to be aware of many browser bugs. Like that site, it will look wrong in MS IE 5.5, because that stupid browser gets all height and width specifications wrong. There is a workaround for that (as usual), but I haven't implemented that yet.

And yes, I would also highly recommend www.alistapart.com on this subject, I have learned incredibly much about modern (CSS-based) web design there.

Actually, as I was trynig to tell Harry, an actual real-world .NET example would have no loop at all. It would simply bind the result set to the output id area, and .NET would handle looping, paging, etc (depending on component used).

That said, CSS transformations have their pluses and minuses as well, and I think rank up there with "one of the options", as opposed to the epitome (the way it sounded like Harry was proposing this, at least to me)... Perhaps he's proposing something which doesn't exist yet?

It's true CSS is another choice and I'm not proposing it some perfect solution today, by any means. But CSS shows how's things can be done. Once browsers catch up reckon it's likely to become the default technology for designers.

Robo - you'll have to see what I was saying here - my fault for not keeping it clear but I was focusing on what various technologies have to offer designers rather than application / presentation logic issues.

In this example, the List isn't actually filled, but that's just a .Fill(), so no biggie. I've also removed the Form Designer code.

Define the area on the .aspx page (DW, Frontpage, VS.NET and Web Matrix will all see a drop down list). Designer does what he wants with the actual HTML. Presentational logic is done in the code-behind.