SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 37
  1. #1
    SitePoint Wizard Mike Borozdin's Avatar
    Join Date
    Oct 2002
    Location
    Edinburgh, UK
    Posts
    1,743
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question Custom Tags And MVC

    Hi!

    There were some mentions about custom tags and MVC and I'm wondering if they break the MVC rules.

    For example, let's take a look at this pseudo code:
    Code:
    <MyApp:if var = "User.IsLoggedIn" is = "true">
      Hello, <MyApp:var name = "User.Name" />!
    </MyApp:if>
    It seems to be a part of presentation logic, so it can be in view, so this doesn't break the MVC. There's also data retrievial tags, but View can get data, so it must be ok.

    But what about this:
    Code:
    <asp:textbox id = "name" /><asp:RequiredValidator ControlToValidate = "txt1" ErrorMessage = "Name is empty" />
    It contains validation, but validation must be in Controller, on other hand your validation can be handled by JavaScript functions, is it a presentation logic?

  2. #2
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Personally, I think that it is a violation of separation of concerns (see other threads), but I don't think you can compare the ASP.NET page - code behind relation 1 to 1 to the View - Controller relation as is discussed in a lot of threads in this forum. It just has a different architecture. It's therefore not a violation of the ASP.NET architecture

    In my view, a View layer should only be concerned with presenting data from the model, i.e. turning it into HTML or some other format. It should not be concered about what data source that data comes from or the rules that dictate the validity of that data. Validation is clearly a job for the Controller and Model, like I explained in another thread.
    Last edited by Captain Proton; Jan 6, 2004 at 09:26.

  3. #3
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Asking a ASP DotNet related question in the PHP forums is looking for more trouble in it's self yes ?

    Like, PHP isn't (thankfully) nothing like ASP DotNet But imo having any kind of IF, ELSE et al conditions within a template is a bad idea

    But that's not to say that'd it break MVC though, if needs be to use conditioning that is

  4. #4
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Asking a ASP DotNet related question in the PHP forums is looking for more trouble in it's self yes ? Like, PHP isn't (thankfully) nothing like ASP DotNet
    Remember that one of the goals for WACT is an ASP.NET template compatibility layer.

    Quote Originally Posted by Dr Livingston
    But imo having any kind of IF, ELSE et al conditions within a template is a bad idea
    This would apply if your idea of a template is to separate logic from presentation. I prefer a template system that separates presentation logic from business logic, and therefore see no reason to disallow simple conditional checks, based on model layer data passed to the template, inside of the template itself.

    Regards,
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  5. #5
    SitePoint Zealot ZangBunny's Avatar
    Join Date
    Jul 2003
    Location
    Mainz, Germany
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    This would apply if your idea of a template is to separate logic from presentation. I prefer a template system that separates presentation logic from business logic, and therefore see no reason to disallow simple conditional checks, based on model layer data passed to the template, inside of the template itself.
    If you want a template system for that purpose, it must be "powerful" enough to handle all presentation logic, so you'll need something very complex, like Smarty et.al, which I don't think is a good idea for various reasons.

    I like to use a template system as the last step in my presentation logic, after preparing the data in straight PHP. (This is still done outside of any "business logic".) This way, the only "logic" I still need in the template is foreach() for iterating over an array, and if() on a single boolean variable for conditional display.
    Things that try to look like Things, sometimes
    look more like Things than Things. - Granny Weatherwax

  6. #6
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you want a template system for that purpose, it must be "powerful" enough to handle all presentation logic, so you'll need something very complex
    Do I hear 'PHP' there?

    I rest my case, because the discussion whether PHP 'is allowed' to be used for template engines is another debate.

  7. #7
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Remember that one of the goals for WACT is an ASP.NET template compatibility layer.
    Yer, I was aware of this, though being me; Where anything MS and DotNet; Not everything has a silver lining if you see what I mean ?

    Just me being picky I suppose huh ?

  8. #8
    Currently Occupied; Till Sunda Andrew-J2000's Avatar
    Join Date
    Aug 2001
    Location
    London
    Posts
    2,475
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Microsoft
    Problem
    How do you modularize the user interface functionality of a Web application so that you can easily modify the individual parts?
    Enterprise Solutions Patterns Using Microsoft .NET

    Model-View-Controller
    Implementing Model-View-Controller in ASP.NET

  9. #9
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There were some mentions about custom tags and MVC and I'm wondering if they break the MVC rules.
    I think you should be more concerned with whether it makes sense to use custom tags in your particular situation, as opposed to whether or not it breaks MVC. As some of us are learning (and others disagreeing with ) in other threads, "breaking" MVC ("deviate" sounds a lot better), might just be the way to find a new, more effective and obvious design pattern. It looks like MVC has taken on a demi-god status that is almost preventing even the brightest minds among us from questioning its validity / usefulness.

  10. #10
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I agree. The reason why I think that coding validation in templates is a bad idea, is that I learned it 'the hard way'. It was a design problem in my application. For me, trying to solve those problems has lead to a MVC like pattern.

    As long as you don't encounter any design problems because you'd mix validation and html, there is no reason that you'd not use it. It totally depends on the nature of your application whether problems will arise or not.

    Nevertheless, I think separation of different concerns is always a good thing, no matter what the problem is

  11. #11
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Validation definitely belongs in the model. The fact that a field can't be longer than 10 characters has more to do with the database and the model than to do with the fact that you are presenting it in HTML using a lovely shade of green. I think ASP.NET validation tags are a very bad idea.

    I am also not a fan of complex conditional logic in templates. Although, I've found the complete lack of conditional logic capability to be cumbersome as well. So far WACT has only two conditional logic tags: <OPTIONAL> and <DEFAULT>. They check only for the existence or non-existence of a variable. The setting of that variable must take place outside the template code. So far, this has been sufficient for what I have needed. The long-term jury is still out.

    I would argue that certain custom tags are very good for MVC. Custom tags allow you to specify the meaning of an element instead of how to present it. The best example I have of this from WACT is the <page:navigator> tag:

    Code:
    <page:navigator id="pagenav" items="10">
        <page:first>First</page:first> <page:prev>Prev</page:prev>
        <page:list>
            <page:number>
            <page:elipses>...</page:elipses>
            <page:separator> </page:separator>
        </page:list>
        <page:next>Next</page:next> <page:last>Last</page:last>
    </page:navigator>
    With this example, the template specifies what to display (10 items per page, dim the first button on the first page, etc) but the logic of how to display it is contained in the tag itself.

    Similar code (taken from tiki-wiki) with generic tags is more complicated:

    Code:
    {if $prev_offset >= 0}
    [<a class="prevnext" href="tiki-webmail.php?section=contacts&amp;find={$find}&amp;offset={$prev_offset}&amp;sort_mode={$sort_mode}">{tr}prev{/tr}</a>]&nbsp;
    {/if}
    {tr}Page{/tr}: {$actual_page}/{$cant_pages}
    {if $next_offset >= 0}
    &nbsp;[<a class="prevnext" href="tiki-webmail.php?section=contacts&amp;find={$find}&amp;offset={$next_offset}&amp;sort_mode={$sort_mode}">{tr}next{/tr}</a>]
    {/if}
    {if $direct_pagination eq 'y'}
    <br/>
    {section loop=$cant_pages name=foo}
    {assign var=selector_offset value=$smarty.section.foo.index|times:$maxRecords}
    <a class="prevnext" href="tiki-webmail.php?section=contacts&amp;find={$find}&amp;offset={$selector_offset}&amp;sort_mode={$sort_mode}">
    {$smarty.section.foo.index_next}</a>&nbsp;
    {/section}
    {/if}

  12. #12
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Selkirk, in principle I agree that validation belongs in the model. But there is one complicating factor involved in web applications: JavaScript clientside validation. A lot of developers want to have javascript validation in their apps, but I don't think that javascript validation code belongs in the model, because javascript validation is 'presentation layer specific' (i.e. an XML-RPC interface does not have javascript validation).

    Because of the above I believe that the best place for putting form validation is in the layer between the view and the model: the controller.

    JavaScript is something that I wish we could just discard, because it would make the discussion (in another thread, though ) a lot easier. It's just a pain in the *** for design patterns like MVC. MVC was not meant for the web, and javascript is something that does not really 'fit' into n-tier architecture either. Sigh...

  13. #13
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think ASP.NET validation tags are a very bad idea.
    Well said

    I am also not a fan of complex conditional logic in templates.
    Couldn't agree with you more either

    Enough said me thinks ?

  14. #14
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    but I don't think that javascript validation code belongs in the model,
    Then your seriously not suggesting Javascript belongs in the VIEW Layer eh ? I'd have to disagree, and say that Javascript does belong in the MODEL;

    But there is more than one point of view of usage of course

    1) Form Validation
    2) CSS Manipulation

    As for example, so maybe folks we should just use Javascript in both the MODEL and VIEW huh ?

  15. #15
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    A lot of developers want to have javascript validation in their apps,
    I wish they wouldn't. I have yet to see a well-done real world example of javascript client validation. This weekend my brother was telling me he couldn't fill out an online-unemployment form using the Safari browser because the javascript in the form didn't work in that browser. What if he as blind and needed a special browser? I'm maintained for years that JavaScript is still too flakey for general use. But I digress...

    Quote Originally Posted by Captain Proton
    but I don't think that javascript validation code belongs in the model
    It doesn't, but the validation rules do.

    Quote Originally Posted by Captain Proton
    , because javascript validation is 'presentation layer specific' (i.e. an XML-RPC interface does not have javascript validation).
    So the javascript validation is a presentational representation of the validation rules defined in the model?

    Quote Originally Posted by Captain Proton
    Because of the above I believe that the best place for putting form validation is in the layer between the view and the model: the controller.
    WACT takes this approach. The form controller reads the validation model that you have built for the form to determine the maximum size of each text input field on the form and adds the maxlength attribute to it with the correct value. The same approach would be used to examine the validation model and generate validation javascript. (BTW, there is an opening on the WACT team for an ambitious programmer to write the visitors needed to convert the WACT validation models into JavaScript client side validation code and prove me wrong about the whole concept of client side form validation.)

    Also, If you consider the controller to be just "the layer between the view and the model," though, you are not really following the traditional smalltalk MVC pattern. However, thats an entirely different thread.

  16. #16
    Currently Occupied; Till Sunda Andrew-J2000's Avatar
    Join Date
    Aug 2001
    Location
    London
    Posts
    2,475
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    I have yet to see a well-done real world example of javascript client validation.
    You might want to look at Peter Baileys (Beetle) example. His websites currently down, however i'm sure he wont mind sending you it.

  17. #17
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Also, If you consider the controller to be just "the layer between the view and the model," though, you are not really following the traditional smalltalk MVC pattern. However, thats an entirely different thread.
    I didn't say I saw it as "just" the layer between the view and the model, I just said that to make my point clear that it shouldn't be in the view nor the model.

    So the javascript validation is a presentational representation of the validation rules defined in the model?
    Yep, you could see it that way I suppose. Imagine that SOAP would have its own language for validating on the remote computer, much like HTML has JavaScript, then I would argue that that language is also 'presentation layer specific'.

    Quote Originally Posted by Selkirk
    Quote Originally Posted by Captain Proton
    but I don't think that javascript validation code belongs in the model
    It doesn't, but the validation rules do.
    Agreed. I guess the reason that I am so much in favour of putting validation rules in the controller is that I have not been able to find a good way of placing validation rules in the model and also supporting javascript validation. Placing javascript code directly in the model would not be right of course. What is needed is some kind of special validation language that can be used to validate server-side but can also be converted to javascript easily. But then of course we're talking about inventing a new language, something which I'm a little bit reluctant to do if there is some way to do it with "just" PHP.

    I can see one serious problem with validation belonging in the model, though. I can think of forms that do need to be validated, but it is not model data that should be validated. An example of this is a search form where you must enter a series of fields of criteria to search on, for example only certain combinations of filled in fields are allowed. That is a kind of form where there is no model data that is validated. Where would you put the validation rules for such a form?

    Another thing, you said you are planning to use Visitors to write the javascript code on WACT. I used that same pattern, but one of the limitations was that it did not allow me to use custom "validation rule objects" (how are they called in WACT? rules, constraints, validators, I don't know), i.e. complex rules that could not be made by combining validation rules that the library/framework provides.

    Visitors are a very elegant approach to the javascript problem, they keep the javascript separate of course, but have you thought about users that would like to create their own validation rules?

  18. #18
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    Visitors are a very elegant approach to the javascript problem, they keep the javascript separate of course, but have you thought about users that would like to create their own validation rules?
    I don't think there is anything you could (or would want to) do about a designer putting javascript into a template. That would work fine. I think the point of the automatically built js validation is to ease development for both the designer and the developer while making is easier on the end user and saving round trips to the server.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  19. #19
    SitePoint Zealot
    Join Date
    Feb 2003
    Location
    Virginia
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    I don't think there is anything you could (or would want to) do about a designer putting javascript into a template. That would work fine. I think the point of the automatically built js validation is to ease development for both the designer and the developer while making is easier on the end user and saving round trips to the server.
    Why is every one tring to VALIDATE js in php? Seems to me you are asking for a headache, you know how hard validating XML is WITH a parser. This is a php weakness - merging with other languages that are interperated. Which developer validates HTML in php? I'll wait, but I'm betting it'll be a while.

    As far as js, it's output should be checked in the view/controller (I share the responsability between the two -view can set, controller can set and validate) like any other PUT or POST (GET ect.. ) data comming from the client. It's just data. Different funny looking data, but data all the same.

    Opinions welcome.
    Res

  20. #20
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    lol, we're not trying to validate JS in PHP, as in checking if some piece of javascript code has a valid syntax We're talking about generating javascript code in PHP to perform validation of a HTML form in a browser..

  21. #21
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Resolution
    Why is every one tring to VALIDATE js in php?
    Not validating js, validating form entry. Making sure about things like when changing a password the hidden values in new1 and new2 are the same before submitting the form to the server. These are nice for the end user becuase they save a trip, but should never be required because
    1) the client may have js disabled
    2) you can never trust the client anyway.

    HTH

  22. #22
    SitePoint Zealot
    Join Date
    Feb 2003
    Location
    Virginia
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Wow, see what happens when I type before the coffee pot gets to full steam?

    Generating JS is not too difficult. I would simply use a template just as I do for the HTML and then pas that back to the calling template.
    The tricky part is making sure that the JS is properly fixed to all the HTML form data. I suspect WACT could handle this wiht is tag style.
    I also belive my own template system could handle such a task as well.


    A quick way to check if the client has JS is to send them a cookie on their first request, then send them a JS to return their browser info/settings. I use a sniffer module that works that out nicely. So before any pages are rendered you know if JS is activated. Still, if they turn it off during that session the whole plan is cooked - void.

    So, mabey it would be bette to build a flash generator since more people are likely to have it and NOT disable it during a session.

    A thought.

  23. #23
    SitePoint Addict
    Join Date
    Aug 2002
    Location
    Ottawa, Ontario, Canada
    Posts
    214
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    Selkirk, in principle I agree that validation belongs in the model. But there is one complicating factor involved in web applications: JavaScript clientside validation. A lot of developers want to have javascript validation in their apps, but I don't think that javascript validation code belongs in the model, because javascript validation is 'presentation layer specific' (i.e. an XML-RPC interface does not have javascript validation).

    Because of the above I believe that the best place for putting form validation is in the layer between the view and the model: the controller.

    JavaScript is something that I wish we could just discard, because it would make the discussion (in another thread, though ) a lot easier. It's just a pain in the *** for design patterns like MVC. MVC was not meant for the web, and javascript is something that does not really 'fit' into n-tier architecture either. Sigh...
    Perhaps my perspective on this is a bit out of whack, but we use specific Form objects to represent a form on a web page

    Simple Example:
    PHP Code:
    <?php
    //create form and elements and add elements to form
    $form=&new Form('form');
    $tb=&new Textbox('text');
    $ta=&new Textarea('textarea','10','30');
    $sub=&new SubmitButton('submit','Enter');
    $fil=&new FileElement('file_el');
    $check1=&new Checkbox('check1','check_val1');
    $check2=&new Checkbox('check2','check_val2');
    $form->add_elements(array(&$tb,&$ta,&$sub,&$fil,&$check1,&$check2));

    //adjust/add attributes and values
    $form->set_method('get');
    $tb->add_attribute('size','10');
    $ta->set_value('default');
    $check1->set_value();

    //add some simple checks
    $tb->add_check('pop','Please enter a username');        
    $tb->add_check('regExp','username must contain only alpha-numeric characters.','/^\w*$/');
    $ta->add_check('length','Feedback must be less than 250 characters.','0,250');
    $ta->add_check('pop','Please provide feedback for explanation.');
    ?>
    I create the form in the Model, and can call the get_rendered_form() method to return the form in an HTML representation (array of elements) which I can then use use in the View to display the HTML for the client.

    It is not a massive leap to adjust the Form model to allow a "create JS" option that can also generate the JS code (based on the checks that have been added), and render that in the View as well.

    Maybe I am dense, but I fail to see what how JS has even one iota to do with the Controller, when ultimately it is never even "used" on the backend. Not to mention I don't buy into doing anything with validation in the Controller. The Controller should control flow based on actions requested, the Model should determine if there is enough/proper data to fulfill that request (if any data checking is needed at all).

    Currently, my Form classes generate the HTML for me, but I am considering changing them to generate an XML representation That can be used in an XSLT type transformation. (I am struggling with the worth of this, since I am not sure I see the value in describing my forms in XML and transforming them to HTML after - I don't know if other "Views" (WAP, etc) allow for Forms in an HTML-like sense and as such, is it worth the effort - but that's another story).

    If I were to go down that route, I could generate the View with or without JS on the fly, no?

    PHP Code:
    //no JS
    $result=HtmlView::get_rendered_form($form);

    //with JS
    $result=HtmlViewWithJs::get_rendered_form($form); 
    Even if I don't go down that route, it is still not a big deal to add JS generation to the Form object, and render it in the view.

    Cheers,
    Keith.

  24. #24
    Currently Occupied; Till Sunda Andrew-J2000's Avatar
    Join Date
    Aug 2001
    Location
    London
    Posts
    2,475
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    Yep, you could see it that way I suppose. Imagine that SOAP would have its own language for validating on the remote computer, much like HTML has JavaScript, then I would argue that that language is also 'presentation layer specific'.

    What is needed is some kind of special validation language that can be used to validate server-side but can also be converted to javascript easily. But then of course we're talking about inventing a new language, something which I'm a little bit reluctant to do if there is some way to do it with "just" PHP.

    Visitors are a very elegant approach to the javascript problem, they keep the javascript separate of course, but have you thought about users that would like to create their own validation rules?
    Currently i'm implementing XForms on the server-side, combined with the use of XSL(T), to handle validation and transformation. This means that an administrator, or a privaledged user, can create a standard HTML Form or any other form of ML, and bind that to an XForms Model. This segregation allows administration to globally, maintain the site...



    Element Attributes Minimal Content Model
    model | Common, Events, functions (QNameList), schema (list of xsd:anyURI) | (instance|xsd:schema| submission|bind|Action)*
    instance | Common, Linking | (ANY)
    submission | Common, ref (binding-expression), bind (xsd:IDREF), action (xsd:anyURI), method ("post"|"get"|"put"|"form-data-post"|"urlencoded-post"|qname-but-not-ncname), version (xsd:NMTOKEN), indent (xsd:boolean), mediatype (xsd:string), encoding (xsd:string), omit-xml-declaration (xsd:boolean), standalone (xsd:boolean), cdata-section-elements (QNameList), replace ("all"|"instance"|"none"|qname-but-not-ncname), separator (';' | '&'), includenamespaceprefixes (xsd:NMTOKENS) | Action*
    bind | Common, Model Item Properties, nodeset (model-binding-expression) | (bind)*

    From this, a set of standard javascript/vbscript or any other client-side scripting language can be bound to each form with the correct method of validation.

    Personally I find this solution far more elegant and maintainable. This does all of the mentioned above, and more in a standardised manner.

    A quick way to check if the client has JS is to send them a cookie on their first request, then send them a JS to return their browser info/settings. I use a sniffer module that works that out nicely. So before any pages are rendered you know if JS is activated. Still, if they turn it off during that session the whole plan is cooked - void.
    Reminds me I must do something similar for XForms players on the client-side.

    Off Topic:


    EDIT: Wish they would allow basic HTML tables.

  25. #25
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    I think the point of the automatically built js validation is to ease development for both the designer and the developer while making is easier on the end user and saving round trips to the server.
    Jason, this is going to sound like a cheap shot and I suppose it might be. As one using Phrame, you surely aren't too concerned about round trips to the server!

    (Due respect, though, because I have a hard time getting my head around Phrame!)

    Still, perhaps a common motivation for using JS validation is to make it easier on the user (fewer page loads) rather than the developer.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •