initialize cls, att, style from element constructor

[Iftahh]

Added cls, att, style parameters to Element constructor

NOTE: to achieve same behaviour from the RemoteDocument element method I changed it in a non-backwards compatible way - it had a feature to initialize multiple elements from kwargs but looks like this feature wasn't used and isn't very useful in general IMHO.

This new constructor params allows creating elements and initializing in one line:

x.element('div', 'this is a text', cls="panel warning", att={'data-key':'bla bla'}, style={'width':'50px'})

instead of: d = x.element('div', 'this is a text') d.cls.append('panel') d.cls.append('warning') d.att({'data-key':'bla bla'}) d.style(width='50px')

[skariel]

Thanks, its a good adddition

[Iftahh]

only the first step...

next steps I plan: 1) implement "shortcuts" - special classes for all different standard html elements (div, span, input, a, ul, li, button, etc...) - learning from Dominate lib 2) implement stacker of elements with "with" statements - parent element will be determined from stack head and visually clear from indentation of code 3) implement full widgets of a major ui framework 4) documentation, tutorial, examples...

On Thu, Jan 30, 2014 at 10:10 AM, Ariel Keselman notifications@github.comwrote:

Thanks, its a good adddition

Reply to this email directly or view it on GitHubhttps://github.com/skariel/webalchemy/pull/142#issuecomment-33667432 .

[joaoventura]

Iftahh, which UI framework do you plan to implement the wrapper?

[Iftahh]

I'm leaning towards Bootstrap because I have past experience with it, so I don't need learning curve to get started. Also I think it is very well maintained and has a huge community so that is a safe bet for future support.

But I will read more about semantic-ui and gumby before I decide. Do you have "sales pitch" why gumby/semantic-ui are better than bootstrap?

At any rate, I plan to make it an optional package - maybe even a different github repository, and I suppose it will be easy to write similar packages for other ui frameworks.

Maybe it is even possible to normalize a few frameworks into a single python API (as much as possible - only for common features) so that the application writer can change UI framework without changing the rest of the code - but that remains to be seen.

On Thu, Jan 30, 2014 at 12:19 PM, João Ventura notifications@github.comwrote:

Iftahh, which UI framework do you plan to implement the wrapper?

Reply to this email directly or view it on GitHubhttps://github.com/skariel/webalchemy/pull/142#issuecomment-33675337 .

[joaoventura]

Bootstrap seems fine! Don't know much about gumby/semantic-ui.. I think someone else proposed it in another "issue", but I don't know them enough.

I am going forward with jquery mobile, I need it for a project of mine. But I would be glad to try to "harmonize" a common architecture, so other UI frameworks could be used/wrapper without much effort.. It would be very good for this project!

[Iftahh]

Oh oops!

It was James Rubino who proposed semantic-ui / gumby, I thought it was you... sorry

On Thu, Jan 30, 2014 at 6:00 PM, João Ventura notifications@github.comwrote:

Bootstrap seems fine! Don't know much about gumby/semantic-ui.. I think someone else proposed it in another "issue", but I don't know them enough.

I am going forward with jquery mobile, I need it for a project of mine. But I would be glad to try to "harmonize" a common architecture, so other UI frameworks could be used/wrapper without much effort.. It would be very good for this project!

Reply to this email directly or view it on GitHubhttps://github.com/skariel/webalchemy/pull/142#issuecomment-33701403 .

[joaoventura]

@skariel and @Iftahh

I am documenting and commenting the remotedocument.py file and I see that the DOM tree is being replicated on the server.

For instance, when we append a button to the rdoc, it calls the append method which appends the button to the element "childs" list in the server, and then sends the Javascript to do the same DOM manipulations on the client. So, basically we have two DOM trees, although the one on the server seems way too heavy, with lots of references.

My question is: do we really need this heavy representation on the server? Couldn't we have just minimal hierarchy representation on the server (or none), and just forward the element creations, destructions, getValues, etc., to the client, since we have a permanent connection?

I'm thinking more in terms of server memory footprint..

[skariel]

First in an unrelated note - I'm now merging SockJS branch with master. Everything seems to work right, there are no API changes, so why wait right?

Now about the issue of DOM at the server- Can you please open an issue about this? I think you are right, something should be done but it is not completely obvious what...

EDIT: Webalchemy now runs on top of SockJS!