On Sunday, July 8, 2012 4:04:34 PM UTC-4, Leslie P. Polzer wrote:
>
> Since interest on Weblocks has picked up recently it's appropriate that I 
> write about what I have in mind for it.


That is all good news. I have been watching weblocks with interest for some 
time, especially since UCW became largely dormant, and finally I have 
something for which I hope to use it in anger. :)
 

> My proposals:
>
> * Create small components with their own systems, e.g. weblocks-base, 
> weblocks-stores, weblocks-forms, weblocks-continuations...
>

I like this idea.
 

> * Decouple these components so that you don't have to deal with 
> store-dependent stuff when you want to roll your own data storage 
> mechanisms.
>

This is also a good idea.
 

> * Get rid of continuation stuff. It's not a common tool, it's a tool that 
> has its merit in special situations but is difficult to understand for 
> beginners, and difficult to debug for experts.
>

Continuations really solve the whole problem of a web app which has a lot 
of state very succinctly... I think that unloading the base system of the 
overhead of continuations may be a pyrrhic victory. It is already possible 
to ignore them -- perhaps making available a more obvious and straight 
forward routing system would achieve the same effect without giving up the 
jewels?
 

> * Provide sane versions of dataform and gridedit that don't depend on 
> stores and are easily customizable. I already have a good dataform 
> substitute.
> * Get rid of Prototype and Scriptaculous in favor of JQuery.
>

Yes! I would dearly love to see jquery in weblocks. I saw in the group 
awhile ago somebody doing a lot of work for weblocks/jquery integration... 
what is the state of that project?
 

> * Move version control to git and the repository to Github
>

I like git. At this point anything that isn't git is just kind of a pain in 
the ass because of the cognitive load of keeping all the ways that 
$VERSIONCONTROL in question is not git.
 

> * Provide a mechanism of generating CSS automatically.
> * Provide good template support.
>

This is interesting. How do you see templates working in the presence of 
the widgetry focused approach of the traditional Weblocks app? as for the 
CSS thing, it would gratify me endlessly if it was possible to plug in at 
the CSS level with look and feel customisations. Specifically, it would be 
really great if we could take something like Twitter Bootstrap and just use 
it with weblocks; what that looks like, I am not sure, because I am just 
starting to look at building something real, but it is a specific problem I 
am going to have to confront Very Soon(c)[tm].
 

>
> If anyone has any other useful ideas or is interested in helping, please 
> chime in. Thanks!
>

See above re. support for CSS look/feel systems like Twitter Bootstrap. 
Making this kind of system easily usable in Weblocks would be a huge win... 
inasmuch as I'm not sure how to do this kind of thing in Weblocks, short of 
writing the javascript manually into every widget under a given view. In 
fact, since I'm looking at how to do this right now, do you or any of the 
other old guard have any pointers on what I should do about CSS and 
ancillary  js in the Weblocks context?

-- 
You received this message because you are subscribed to the Google Groups 
"weblocks" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/weblocks/-/9WUOsLhdjVMJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/weblocks?hl=en.

Reply via email to