I am working with server side code.

I have a request object that handles request data validation and filtering.

I have a view object that uses template files to generate html for output. the template files are mostly html. you can put one view object inside of another view object in order to assemble a page piece by peice. for instance you might have a page layout view, and you might put a form view inside the page layout view.

One of the features of the request object is that it can automatically build validations using an html5 string containing a form. It parses the html string and grabs input types and other tag attributes that determine HTML5 validation, then matches this validation server side. I get this html string from a view object. This way no matter what the designer puts in the view's template file, it will automatically get validated according to the html5 attributes server side.

i create and use the same view that was originally used to generate the page, to build validations for the request when the page is then submitted back to the server.

I would like to get feedback on this idea. Pros/Cons/Other Concerns.

  • I didn't downvote you, but your question isn't very clear, so that would be my guess. – psr Sep 30 '11 at 23:05

I still have no idea why you're insistent on parsing HTML (whether it's in a template or not). It's just a bad design (imho). The template is the presentation piece, which the model (or seemingly the view model in this case) should know nothing about. By parsing the HTML, you're introducing tight coupling needlessly.

If the intent is to make it easy for designers to work with (I have no idea why designers are working with code, HTML/CSS or not), then let them stick to writing the templates. But, have them also create a file (JSON perhaps?) that contains meta information about each view. When the validation routines execute, all they have to do is check the meta data against the POST data and validate each one accordingly.

For example:


<form action="/accounts/create" method="POST">
<!-- other stuff here -->
<input type="text" name="fname" />
<input type="text" name="bdate" />
<!-- other stuff here -->

JSON meta-data:

    "action": {
        "url": "/accounts/create",
        "inputs": {
            "fname": {
                "type": "text",
                "maxlen": 25
            "bdate": {
                "type": "date"

Now, you'll have PHP code that will get the URL from the request, match it to a specific JSON entity and run all of the validation routines that you want on it.

What do you get out of this?

  1. It's easy. It's readable.
  2. Writing a tool to automate the JSON creation should be trivial (if you really wanted to, here's where you could parse the template to generate the meta-data).
  3. There's no parsing to be done (other than the initial hit you'll take for parsing the JSON, which is miles better than parsing HTML, especially during a response).
  4. It separates your presentation layer from your view logic. You could turn your template into a client-side-driven jQuery template rendering and it wouldn't matter. All that matters is that the names of the form elements match up to those in the JSON.

That's most likely how I'd go about doing something like this.


In the "other concerns" category, the first 4 words, "I'm building a framework" are actually a red flag. "Framework" isn't well defined enough that I can be sure what you mean, but generally you want a library or toolkit more than a framework. Framework usually implies that if you use it then you have to do everything within it, which means you can't also use someone else's framework, or do things the framework wasn't designed for. If so, it had better be a really good framework, which means it probably isn't worth the time to write it.

Of course what you are writing might even be more of a library than a framework, so it's just something to think about.

As for specifics, if your view object is on the server side and not coming from the browser it's not too bad, though then I really have no idea why it would be an HTML5 string (which I assume is a string that parses as valid HTML5?). In that case, HTML5 is horrible to parse and apparently pointless, so you should send an object (like, the view object, perhaps).

I have no idea what you mean by the designer - is that a class or a human?

I think it's a human, in which case Demian Brecht has it quite right. I suppose if the validation is in no way for security and you really don't care if users circumvent the validation rules then it isn't that bad, but you still have to parse HTML5. In which case you'd better have a library handy - please oh please don't use regular expressions. And it still might be harder than using a form - is there a reason you aren't using a form?

Also, think about how hard adding validation will be if you ever need something not addressed by HTML5.

You might get better answers if you explain why you are doing what you are doing (and are clearer about what).

  • @dqhendricks - Sounds a lot better then I thought just from your question. I still don't know why you want to do the validation server side - won't the client do it. And doing it again on the server won't help if the client can circumvent it, which it sounds like they can. Why not use the parser to code-generate server validation rules prior to deployment - then clients wouldn't be able to get around it and you wouldn't spend server resources parsing at run time? – psr Sep 30 '11 at 23:23
  • how can the client circumvent it if the html the server is parsing is stored on the server? – dqhendricks Oct 1 '11 at 1:02
  • It sounds like what the server is parsing is the HTML coming from the client. If so, the client can send different HTML. If it's coming from the server, why HTML? If it's something you create entirely, why make it HTML just so you can parse it back out of HTML again? Are you parsing a page just before you send it to the client, or saving the string from then and using that for validation later? It's really unclear what you are doing. – psr Oct 1 '11 at 1:12
  • i make it html because thats the easiest medium for the designer to work with. server outputs html with form in it. when form is submitted back to the server, the server uses the original html to build the validations to process the received request. i am asking why not just use html? – dqhendricks Oct 1 '11 at 2:23
  • i have edited the question to try to make it clearer. – dqhendricks Oct 1 '11 at 2:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.