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.

Yes that's possible but you still lose things like a:hover, a:active... So I think just leave it to designer. If no-scripting support is mandatory then he's not allowed to use link button.

Fine. I just figured that in an argument about style vs. function that function would win out, namely that my code works with javascript disabled. I think that's worth sacrificing :hover type functionality.

Actually, if you just think for instance of regular expression based validation rules, most people with only presentation design knowlegde will get knots on the brain just trying to understand the regular expression language syntax, even more trying to define non-trivial regular expressions all by themselves.

the designer does not need to know regexp. he just need to add a <validator> tag somewhere in the page (where to display the error message), programmer will edit the pattern either on the page or in code.

Originally Posted by mlemos

I don't know if .NET really can provide all that the forms class provides. What I asked and it seems you moved away from the question, is in terms of forms management, what does the ASP.NET provides that the PHP solutions don't and would consist in an advantage of using the ASP.NET approach?

The only advantage is that I can write little code. There's nothing asp.net can do but php can't (my engine is a clear example).

I completely disagree. Validation rules are part of the Model and not of the View in a MVC approach. Presentation designers should never need to know and understand how to implement validation rules because it is not their competence, just like presentation design is not the competence of programmers, unless you are on a single person project or your project structure is so bad that you can't split competences.

What’s not so great (in my view) is that the current design of the JSF validation tags assigns the responsibility for defining field validations to the page author. To validate a field value, the pages author “registers the validator on a component by nesting the validator's tag within the component's tag" (excerpt from the JSF tutorial).

This bothers me because it requires the page author to have knowledge about a field’s meaning in order to select the correct validation tag.

Thats cool , & I do not suggest that frameworks & OOP are of no value just perhaps oft-misused in the interpreted world of PHP, & in that vein

ASP.NET in PHP is possible! ..

begs the possible alternate suffix 'but why would you' (a view I hold for creating cloned JAVA libraries in PHP) , again no disrespect intended to the writers of such code , I just have to chuck in my 2c.

Your code snippet is of interest as I have similar looking routines , the difference being that my version will output PHP/HTML (and supporting classes for common routines(paging etc)) to be uploaded and parsed instead of being used at runtime themselves , this of course can be messy (ok it is) and has several drawbacks , however absolutely none at the most important (IMO) time, runtime.

Originally Posted by hongnk

Yes there is trade off for speed but not very much when application grows big.

big is not the issue , server-load & resource usage is the issue , optimizers and cacheing can mostly overcome this , if so then all is well ,though that would be more of interest to those with control over their hosting/hardware than the 'average' PHP user.

Hopefully your code will be run millions of times for every time you have to code it , so I prefer to give execution preference in terms of performance.

the designer does not need to know regexp. he just need to add a <validator> tag somewhere in the page (where to display the error message), programmer will edit the pattern either on the page or in code.

You are still missing the point. What you are saying is that to added or update a validation rule you need a graphic designer to edit the scripts.

What I am telling you is that is counterproductive (not to say more expensive) in a project where the graphic designer and the programming developer is not the same person.

This is why it is a good idea to completely split the presentation logic from the application logic so graphic designers and programming developers do not have to interfere in each other work and the whole project develops much faster.

I feel bad for adding to the "off-topic-ness"... But in all of the years I've been doing web production work, I've never seen a real, working and practical situation where: the designer never touches "code" and the programmer never touches "design". I think that in the real world, both sides need (or should) know a little about both.

Matt

EDIT: of course for the design end of things, I'm talking about presentation logic (not application).

Thats cool , & I do not suggest that frameworks & OOP are of no value just perhaps oft-misused in the interpreted world of PHP, & in that vein

ASP.NET in PHP is possible! ..

begs the possible alternate suffix 'but why would you' (a view I hold for creating cloned JAVA libraries in PHP) , again no disrespect intended to the writers of such code , I just have to chuck in my 2c.

Your code snippet is of interest as I have similar looking routines , the difference being that my version will output PHP/HTML (and supporting classes for common routines(paging etc)) to be uploaded and parsed instead of being used at runtime themselves , this of course can be messy (ok it is) and has several drawbacks , however absolutely none at the most important (IMO) time, runtime.

big is not the issue , server-load & resource usage is the issue , optimizers and cacheing can mostly overcome this , if so then all is well ,though that would be more of interest to those with control over their hosting/hardware than the 'average' PHP user.

Hopefully your code will be run millions of times for every time you have to code it , so I prefer to give execution preference in terms of performance.

I have to agree as well -asp.net provides different functionality in many regards then PHP. If I wanted to use .net templates, I would use .NET - they are native, so theres a speed boost, and I can take advantage of all the asp.net functions.

I use PHP templates - I think they're easier to use then any other of the php-template engine solutions. Learning the basic PHP structures only takes a few seconds - if, while, foreach. A lot of designers have basic PHP skills as well. THis makes PHP templates (html with basic PHP for looping and conditionals) particualrily useful since theres little to no learning curve.

Theres a substantially higher learning curve using both the backend and the template-end of your system - this must be taken into account for production time.

You mentioned theres a five month difference in production time between your engine and any others - I dont even see how this is possible. Given the same site, why would choice of engine make a 5 month difference? Would you please elaborate?