On Mon, 2005-11-21 at 13:41, Dan Baker wrote: > "Robert Cummings" <robert@xxxxxxxxxxxxx> wrote in message > news:1132257406.18353.24.camel@xxxxxxxxxxxxxxx > > Here is an example of a layout template: > > > > ----------------------------------------------------------------------------- > > <jinn:prepend/> > > <html> > > > > <head> > > <title><jinn:pageTitle/></title> > > > > <style type="text/css"> > > <!-- > > <jinn:template path="css/main.template"/> > > --> > > </style> > > > > <jinn:accumulatorFlush name="javaScriptTags"/> > > <jinn:accumulatorFlush name="javaScriptTags" dynamic="true"/> > > > > // --> > > </script> > > > > </head> > > I'm curious ... how do you generally handle forms and urls? What if the > programmer wants to add a link, something like: > <a href="page.php?op=View&id=1234">View my info</a> > > How is the data (op=View&id=1234) separated from the formatting? There are two ways for retrieving data. The first you have seen is the tag form, but obviously that's a problem when the data goes into a tag :) For this there is the embed form (a simple example follows but data can be retrieved from modules/components in the same way): <a href="page.php?op=View&id={jinn:echo value={jinn:getValue name=_GET, path=id}}"> Embeds can be nested as can tags. Additionally, embeds can be used outside of tags, they're just most convenient there. With respect to forms, InterJinn supplies a form engine that does most of the rendering, and which can be assigned to slices. Then output is as simple as: <jinn:render name="someModule" selector="formOpen"> <jinn:render name="someModule" selector="country_field"/> <jinn:render name="someModule" selector="formClose"> Or if you want to customize the form field but still have the internal validation semantics: <jinn:render name="someModule" selector="formOpen"/> <input type="text" name="country" value="{jinn:echo value={jinn:getValue ...}} size="20" /> <jinn:render name="someModule" selector="formClose"/> As long as you use the internal form open and close semantics, and use the same name given to the field internally, you can render the field as you would in HTML. I generally don't use that method, since I like to use configuration arrays or properties to determine how the fields look. Either way, the engine is very flexible and gives the developer lots of choice in how they go about the display and how much control they give the designer. Unfortunately the documentation for the form engine isn't currently up to date, since I've added less cumbersome techniques for creating forms than what it currently documents. The faster techniques don't require working with the objects but rather just define configuration arrays that then generate everything else. Let me know if you have any other questions. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
