Hi Yehuda,

I grabbed your plugged and tried it out.   I think I can used it with
some enhancements I am going to suggest <g>.

First let me tell ya what I found.

I got your simple first/last tag demo to work, but using that as a
model for a test page I have already been working on for data/html
binding, but I can't get it to work.  By that, I mean, nothing showed
up:

I started with this:

  <body>
    <div class="_template" id="myTemplate">
      <![CDATA[
        <table>
        <tr><td>Session #:</td><td>{{cid}}</td></tr>
        <tr><td>Time:</td><td>{{time}}</td></tr>
        <tr><td>Total Users:</td><td>{{TotalUsers}}</td></tr>
        <tr><td>Total Calls:</td><td>{{TotalCalls}}</td></tr>
        <tr><td>Total Msgs:</td><td>{{TotalMsgs}}</td></tr>
        <tr><td>Total Files:</td><td>{{TotalFiles}}</td></tr>
      ]]>
    </div>
    <a href="/code/jqupdate.wcx?cmd=status" rel="#myTemplate"
class="updateTemplate">Click</a>
  </body>

The jqupdate.wcx is a server-side pcode (compiled) applet that runs on
our server. I have this WCX returning JSON formatted structures.
cmd=status returns something like this:

{Time:'01:06:46',Cid:'339',TotalMsgs:'33424',TotalFiles:'1179',TotalCalls:'17506',TotalUsers:'475'}

and the call was made, but it appeared like the template is not
processed

After exploring everything I can think of using plain vanilla divide
and conquer techniques (meaning trying to get it down to match your
demo),  I finally found that the tags are case sensitive.

Changing the WCX and {{fields}} to lower case and now it worked!  The
template was processed.!

I like it!

Suggestions:

I passing long time engineering tips based on our own system so
consider these very practical. :-)

1) Case Insensitive Tag Support

Case sensitivity issues are for code, language or tools progammers,
not higher level end users or application developers. :-)

For something like this,  application developers are going to use
capitalize tags for readability, "TotalFiles" as oppose to"totalfiles"
should not make a difference or be a requirement.

2) Always process the template

Even if the tags are not found or error display the template.  This
will help developers debug their templates, i.e, a typo in a
{{field}}, etc.   You might want to offer an option to return blank
for tags not found instead of just displaying the tag.  The reason is
straight found.  Some tags are blank or empty strings, so to reduce
server template memory, some times an application may not save blank
fields.  For JSON, the applet may not wish to pass it along.  I
suggest the latter should be default (blank for tags not found) and
then offer a "debug" flag to show tags that are not found to help
debug templates.

3) Add Extended Syntax:

Consider adding an extended JSON syntax support . This will give your
pluging flexibility and growth potential.   I provided some examples
below how the extended syntax can come into play.

4)  Consider adding some common Ad-Hoc (JSON) Table Reporting
Templates.

Many people may want to create common reporting display output for a
JSON "result set", like tables like I have above.
Your plugin would automatically create it based on the number of
fields in the JSON using the tag name as the field name.

In practice, this is highly desirable especially in the corporate
setting since most of time that it all you want as they do with
standard ad-hoc report generators.  It would be one less thing that
has to be created in the HTML.

Now, if you only did it at the basic level with simple JSON output,
that would be great 80% of the time, but you can also extend it so
that the JSON data can help define some basic reporting attributes.

(Side Note: I clearly understand the philosophical debates regarding
separatring data vs rendering.  In addition, I'm still new to JSON
constructs, so I am not an expert yet in easily transformation data
into JSON.  Seems easy, but I'm still learning. So use this below to
illustrate only)

Basic Minimum Syntax:

{tag:value.....}

Extended Syntax:

{
Settings: (title, direction, [field_names], {css} }
Data: {tag:value...} or [ {tag:value...},   {tag:value...}....]
}

Example: Single column table sing the JSON tags as cell name.

{Time:'01:06:46',Cid:'339',TotalMsgs:'33424',TotalFiles:'1179',TotalCalls:'17506',TotalUsers:'475'}

Example: Same as above using extended syntax with title.

{
  Settings: {Title:"Server Status", Direction: Single}
  Data:
{Time:'01:06:46',Cid:'339',TotalMsgs:'33424',TotalFiles:'1179',TotalCalls:'17506',TotalUsers:'475'}
}

Example: Multple column table
{
  Settings: {Title:"List of files", Fields: ['File Name', File Size',
'Upload date']}
  Data:
   [
       {Name:"xxxx.zip", size: '12312', date: '2008/08/10"},
       {Name:"zzzzzzip", size: '32423423', date: '2008/08/10"},
       {Name:"yyyyy.zip", size: '14543543', date: '2008/08/18"}
   ]
}

5)  Add some JSON flow controls

Here we want JSON to "control" AJAX. For example, in my server status
example I want to update every 10 second using a get method..  You can
do this with the extended syntax:

{
  Ajax: {Poll: 10; href: "/code/jsupdate?cmd=status", method: 'get''}
  Settings: {Title:"Server Status", Direction: Single}
  Data:
{Time:'01:06:46',Cid:'339',TotalMsgs:'33424',TotalFiles:'1179',TotalCalls:'17506',TotalUsers:'475'}
}

Thats it for now!

Great Plug-in!!   Maybe I can help you make it even Greater! <g>

If you like you can email me directly to discuss it.

--
HLS

Reply via email to