PURE in Reverse?

[AJ ONeal]

When I first found PURE what I was looking for was something to the effect of an ORM for Javascript (I'm a fan of SQLAlchemy, ActiveRecord, and Doctrine) but using JSON instead of a database. 

However, I'd also like to go in reverse, give a directive and get the data from a collection of nodes (mostly forms).

Are there any plans add this kind of feature to PURE?

I know that there's a storage specification for HTML5. I haven't looked into it enough yet, but I assume it could store json or will be sqlite-ish and hence this would be a very useful feature.

AJ ONeal
(317) 426-6525

[chloec]

A simple directive like 'input@value':'person.name' would be easy to
reverse.
But if you start using a function or concatenation, that's becoming
harder to reverse.

I tried different approaches, but I haven't find a simple and fast one
so far.
Do you have an idea on how it would ideally work?
Would some techniques you know from SQLAlchemy, ActiveRecord, and
Doctrine that could fit wiht javascript?

The way I ended parsing our forms is using the name attribute of the
form elements.
<input name="person.name" ...>

The json is updated/built from parsing these "name" attributes.
Nothing fancy, but it is fast and easy.

[andrei]

I'd second that PURE in reverse would be a killer feature.

I imagine admin interface, where I can double-click HTML elements
described with PURE directives, and they would be replaced with
appropriate edit controls, and then the data would be serialized back
in JSON and saved.

[Mic (BeeBole)]

It's intriguing to not say interesting ;)
Could you describe with more details a simple example of what you
imagine?

[andrei]

I'd like an ability of creating simple sites in HTML, having simple
javascript admin interface with PURE like directives that map controls
(inputs, textareas, or even some custom fields) to DOM elements.

Onlick event on elements replaces them with mapped controls. Then,
after edit, the data is serialized into JSON and sent to the server.
Server then uses the same directives to populate the HTML with the new
JSON data.

Its just an idea. I don't know if its possible or how difficult to
implement it.

[AJ ONeal]

On Mon, Jan 18, 2010 at 10:33 AM, andrei <andr...@gmail.com> wrote:

I'd like an ability of creating simple sites in HTML, having simple
javascript admin interface with PURE like directives that map controls
(inputs, textareas, or even some custom fields) to DOM elements. Onlick event on elements replaces them with mapped controls. 

This first part seems more of a style / widgeting issue than a data templating issue.

I've seen a methodology for doing this that I believe works something like this:

Use jQuery to assign onclick events to all input elements that toggles the class 'look_like_plain_span' and puts a blocking div on top or replaces the input with a div.

.look_like_plain_span {

    border: none; /* rids text boxes)

    background: white; /* helps with ridding of text boxes */

    text-decoration: none; /* rids radio boxes.... i think */

}

By default have a transparent div z-indexed on top on the input so that the user can't click in the input, but when the div is clicked it move back and removes the 'look_like_plain_span'

Viola, now the thing that looked like an input looks like a div or vice versa.

This can be applied to an existing form fairly unobtrusively.

Then,
after edit, the data is serialized into JSON and sent to the server.
Server then uses the same directives to populate the HTML with the new
JSON data.

That serialization part is the part I see as being the "PURE in reverse". Currently jQuery serializes the input attributes as well as the data, which is not desired for what you and I want.

Furthermore, I think that server-side presentation layers could use some bi-directional PURE magic. 

I'm really enjoying how simple and clean PURE is. Makes internationalization a breeze too. (I haven't done any yet, but I'm creating sites with dummy data "Title Goes Here" that's replaced with the real title, so I can see how easy it would be.

[andrei]

On Jan 18, 10:15 pm, AJ ONeal <coola...@gmail.com> wrote:
> I've seen a methodology for doing this that I believe works something like
> this:
>
> Use jQuery to assign onclick events to all input elements that toggles the
> class 'look_like_plain_span' and puts a blocking div on top or replaces the
> input with a div.
>

I'd like HTML elements to be replaced with controls in place when
clicked. I don't want HTML to have all the inputs, textareas, etc. A
little like Firebug's inspect element feature, that allows to modify
elements, but with an ability to define which elements are editable,
and what controls they have to be replaced with. And I'd like to do
JSON serialization of the data to be able to commit changes on server.

[Mic (BeeBole)]

On Jan 18, 10:18 pm, andrei <andre...@gmail.com> wrote:
> On Jan 18, 10:15 pm, AJ ONeal <coola...@gmail.com> wrote:
>
> > I've seen a methodology for doing this that I believe works something like
> > this:
>
> > Use jQuery to assign onclick events to all input elements that toggles the
> > class 'look_like_plain_span' and puts a blocking div on top or replaces the
> > input with a div.
>
> I'd like HTML elements to be replaced with controls in place when
> clicked.

Sorry I still don't get it...

What element for instance you would focus/click on?

I don't want HTML to have all the inputs, textareas, etc. A
> little like Firebug's inspect element feature, that allows to modify
> elements, but with an ability to define which elements are editable,

What do you mean by an editable element?

> and what controls they have to be replaced with. And I'd like to do
> JSON serialization of the data to be able to commit changes on server.

Is the name attribute trick used by many frameworks is ok for you or
you have another idea?
Cheers,

[AJ ONeal]

> and what controls they have to be replaced with. And I'd like to do

> JSON serialization of the data to be able to commit changes on server.

Is the name attribute trick used by many frameworks is ok for you or
you have another idea?

As for myself, no that doesn't work. Because you end up with

{

   "name" : "first_name",

   "value" : "Bob"

},

{

   "name" : "last_name",

   "value" : "Dole"

}

whereas I want 

{

    "first_name" : "Bob",

    "last_name" : "Dole"

}

Thinking outside of strict browser-webservice relationships I want something that will be standard across a variety of clients which will access my webservice. In my opinion, JSON support is easier to implement than html forms support.

Hence, I'd like to keep things JSONic from end to end for all clients.

The only problem is that JSON won't transfer binary data. Because of this it's certainly arguable that the web service should serve application/json and expect application/x-www-form-urlencoded or multipart/form-data in return.

AJ ONeal 

[Mic (BeeBole)]

JSON needs at some point to be rendered into a human format.
HTML is ok for that in a browser. Other targets may use something
else. But then how to parse it back?

During our years with XML/XSLT Hughes and myself have looked at many
options to get this effortless holy grail of XML -> HTML -> XML but it
was never working well cross browser and for some crazy forms.

The best I found for HTML, is to loop on the form.elements, take the
string in the "name" attribute and use it as the path to build the
json object. But something need to be done !-)

On Jan 22, 9:09 pm, AJ ONeal <coola...@gmail.com> wrote:
> > > and what controls they have to be replaced with. And I'd like to do
>
>  > JSON serialization of the data to be able to commit changes on server.
>
>
>
> > Is the name attribute trick used by many frameworks is ok for you or
> > you have another idea?
>
> As for myself, no that doesn't work. Because you end up with
> {
>    "name" : "first_name",
>    "value" : "Bob"},
>
> {
>    "name" : "last_name",
>    "value" : "Dole"
>
> }
>
> whereas I want
> {
>     "first_name" : "Bob",
>     "last_name" : "Dole"
>
> }
>
> Thinking outside of strict browser-webservice relationships I want something
> that will be standard across a variety of clients which will access my
> webservice. In my opinion, JSON support is easier to implement than html
> forms support.
>
> Hence, I'd like to keep things JSONic from end to end for all clients.
>
> The only problem is that JSON won't transfer binary data. Because of this
> it's certainly arguable that the web service should serve

> *application/json*and expect
> *application/x-www-form-urlencoded* or *multipart/form-data* in return.
>
> AJ ONeal