On 5/24/07, James Masters <[EMAIL PROTECTED]> wrote: > 1. Presently I just put write the html tags in my code and I'm very > familiar with this. But was looking at Rose::HTML::Objects. Is the main > benefit of this simply to avoid having to write lots of html tags in your > code when writing html forms? Or does this also help me avoid worrying > about field types. For instance, can I shove the metadata of a field into > an HTML object somehow and then inside an HTML form, it will magically > produce the correct input field. e.g. if it were an ENUM field, it would > show a drop-down choice box and if it were a BLOB field, it would show a > textbox instead of a normal one-line text field? If it's the former, then > I may be best off sticking with what I do already. If it's the latter, well > that would a great time-saver.
RHTMLO divorces the concept of a "field" from a single HTML element, and in doing so provides input/output filters, inflate/deflate, and validation. A single field that exemplifies most of these concepts is a date/time field made up of several text fields (say, m/d/y h:m:s) and a pop-up menu for am/pm. As far as your form is concerned, this collection of HTML input and select elements can be treated as a single field. Internally, it returns a single value to your code: a DateTime object. Conveniently, since RDBO accepts DateTime objects for most date/time fields, you don't have to worry about what the database expects for a particular column when writing your HTML form code. The use of such interchange formats makes your validation code simpler (it's easier to check a DateTime object or, say, compare two DateTime objects than it is to do the same with human-input strings) and isolates your forms from your database. You also have the freedom to change that field to a different type entirely (say, a single text field with a JavaScript calendar pop-up) without having to change any of your form handling code. A single field can even return multiple values. An example of this is a date/time range field that returns two DateTime objects. Again, this ties into RDBO nicely as these DateTime objects can be fed right into a Manager query. If your database supports infinity/-infinity you can even have the field return DateTime::Infinite objects when a min/max date/time field is left blank, again passing values on to the Manager call as-is. Finally, RHTMLO does something similar for forms, allowing them to be "conceptually nested." Actual HTML form tags cannot be nested, but RHTMLO will nonetheless allow you to embed one form inside another. The example from the docs shows straightforward nesting: http://search.cpan.org/dist/Rose-HTML-Objects/lib/Rose/HTML/Form.pm#NESTED_FORMS but another common scenario is for forms where a sub-form is repeated N times (e.g., "add another N items", where a form would embed N "add item" sub forms). > 2. Does Rose::HTML::Objects assist me with assessing and checking and > generally dealing with the incoming data from an HTML form? Yes, there are hooks at all levels for validation and query handling. There are also some built-in benefits like the fact that a bad value for a pop-up menu will never get through. (e.g., If pop-up "blah" menu has choices A, B, and C, a malicious query parameter value blah=Z will never result in the "blah" field having a value of Z when accessed from your internal code.) > 3. This app I need to write seems to be such an obvious thing that I'm > wondering if I am trying to reinvent the wheel. Does there already exist a > Rosified version of an HTML front end for editing the data in any database > generically? IIRC, a few people have worked on something similar, but I don't remember who or what state they're in. > Also, I see there is an unreleased thing called Rose::WebApp - > should I be waiting for that?? No. What's in SVN is one of many thrown-away prototypes. It'll be a while :) > 4. Or does database data vary so widely that a truly generic app of this > sort couldn't be written because one normally needs to taylor the html forms > to a certain degree to allow for number, size and types of fields. I mean > it seems to work for my databases but perhaps the output would be non-ideal > for other peoples'. What any such app will have to do is determine an appropriate field type for each column type. Since RDBO and RHTMLO use abstract type names for columns and fields respectively, it's "just" a matter of mapping one type name to another. But there are many valid choices, so a lot of it comes down to taste and policy decisions. > Questions for general discussion as well as for my own selfish purposes! Don't forget that there's a dedicated list to RHTMLO if you have more specific questions. https://lists.sourceforge.net/lists/listinfo/rose-html-objects Here are the recommended starting points in the RHTMLO docs: http://search.cpan.org/dist/Rose-HTML-Objects/lib/Rose/HTML/Form/Field.pm http://search.cpan.org/dist/Rose-HTML-Objects/lib/Rose/HTML/Form.pm http://search.cpan.org/dist/Rose-HTML-Objects/lib/Rose/HTML/Form/Field/Compound.pm -John ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
