On Mon, 2005-11-21 at 18:46, Dan Baker wrote: > "Robert Cummings" <robert@xxxxxxxxxxxxx> wrote in message > news:1132600810.27185.32.camel@xxxxxxxxxxxxxxx > > On Mon, 2005-11-21 at 13:41, Dan Baker wrote: > >> 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}}"> > > It appears that the data "op=View" is embedded in the html data. This seems > strange, because the PHP programmer is the one who needs to set this value, > not the page designer. You asked for a sample of how to do dynamic link parameters. Dynamic parameters can come from many sources (_GET, _POST, component, foreach, etc). I gave you an example of one parameter being dynamic, the first I left as static since perhaps the page itself determines the value. InterJinn's TemplateJinn employes a data "pull" philosophy. Component developers make available data and templates consume it (reverse of smart which forces developers to import templates and populate the template). Generally for simplicity I just set member vars on the component object. But vars can be set anywhere depending on what is agreed upon by the developer and the designer. The render tag bypasses lower level data retrieval and just requests a chunk of output by selector name. > Also, the jinn:getValue seems a lot like programming -- The "id" value must > come from a database, based on who is currently logged in. I assume it can > be done, but seems like these queries would get rather complex, as well as > redundant. Decisions are made in any design. Since InterJinn employs data pull mechanisms, and modules/components are created to be consumed by templates, such that designers can import any module they want (and as many) and just layout the data how they please, it was imperative that one module's data not stomp on another module's data. In this way the {getValue} embed drills down into the data structures of an existing array or object. is this programming? Not really, it's no more programming than you opening up a dictionary, jumping to the A section, and then looking for Apple. This is data retrieval. > Seems like you are changing from programming in PHP to > programming in this new jinn language. TemplateJinn employes very few logic techniques. Business logic is expected to occur in the modules/components/compilers. I guess in the above example I could have used the following instead: <a href="page.php?op=View&id={jinn:render name=someModule, path=id}"> But this presumes the id comes from a module. I just showed an example of retrieving the ID from the GET parameters to the current page *shrug*. Also, it is true that TemplateJinn introduces new syntax, I never said it didn't, but I am happy to pay the small price of some new syntax to increase the readability and brevity of my templates. > The "id" value must come from a database, based on who is > currently logged in. As pointed out in a previous post, a developer can wrap such low level data requests in custom tags. if I want cross site template access to the currently logged in user's ID then I'd add a custom tag to do the following: <a href="page.php?op=View&id={project:user field=id}"> > I am interested in how this works, but am skeptical. No problem, the "programming in X template" instead of "programming in PHP" objection is raised often. I've given previous arguments about the merits of templates and concise data retrieval, display logic versus business logic, and meta tags versus traditional tags. Everything done in TemplateJinn can be done in PHP, absolutely since templates compile to PHP pages, but templates provide a layer between the soup of PHP necessary to accomplish that, and the designer. Even as a developer I don't want to engage in the soup necessary to accomplish everything TemplateJinn now does for me -- unfortunately I maintain some sites that do employ the soup system. 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
