Weblocks frontend future

[o_z]

This subject is associated with "Future plans" subject https://groups.google.com/forum/?fromgroups=#!topic/weblocks/IG0Rm0iv-qc and more precisely with following puncts

* Provide a mechanism of generating CSS automatically.

* Provide good template support.

* Get rid of the test suite. Try to write a frontend-based testing mechanism (I probably won't do this).

Since weblocks is component-oriented framework its css code and templates must be also component oriented, my friend html/css coder mentioned about how it is hard to use twitter bootstrap when coding frontend (css) and how it is easy to use BEM. As I see now twitter bootsrap is not component oriented (or not as component oriented as it could be) and I propose to look at BEM http://bem.info/method/ . This is connected with #1

So in near future weblocks must enrich with visual test suite, after that we can replace some widgets with template-based ones.

For templates I'm using cl-mustache which surprised me and is best template engine I know. I combine it with cl-yaclml (using own macro https://gist.github.com/4077356) and recommend both libraries for work,  it is better to use weblocks standard cl-who for newbies though. (this is for #2)

In far future I see some integration of BEM methodology into project. I think there is no need to integrate javascript and html template parts of BEM into weblocks but css part of BEM is what we need - component-oriented approach. And as I know BEM allows to do such stuff. On the other hand we can use own BEM-like approach.

So with this plan I don't see need in integrating twitter-bootstrap or analogs into main code, but don't discard such possibility. And twitter-bootstrap is near future of weblocks since there are already two attempts to integrate it, but I personally tend to use it separately from weblocks main repository. 

And nearest part is visual test suite on which I plan to start to work and for which I plan to use selenium. (this is for #3).

I have some developments in all I've just talked like https://github.com/html/weblocks-mustache-template-form-view or https://github.com/html/weblocks-twitter-bootstrap-application and some other in my github profile. If you have something to add or share you are welcome.

[Brian O'Reilly]

Okay, now that I've had the chance to read through the link provided on the BEM methodology, i have some commentary. The most notable thing that comes to mind is that this methodology is already pretty much the way the structure of a weblocks application forces us to work. In my playground code I have declared header, footer, and body widget blocks with their accompanying (make-*) utilities... what isn't clear to me is that pushing the templating of the componentry into static free-standing files is a good idea. It would be much nicer if we could define an object protocol for styling that was generic enough to attach arbitrary styling and js code fragments to it. Forex: my current challenge to excellence is overriding the class attribute to the html serialisation of the output of a :navigation widget. It seems to me at the moment (I'm still muddling through the weblocks source code, trying to learn it) that as far as weblocks is concerned, the serialisation of a :navigation is fixed in the base system. If weblocks were to be taken in a direction that would make it theme-able, the obvious place to do that is not in external templates, but in the pre-existing machinery for handling the definition of widget views. The idea of an external templating system seems to completely undermine the origin notion of weblocks, which was "Never write html by hand again".  It would be, however, hugely beneficial if it was simple to take a styling protocol that was inherited by the basic componentry of weblocks, and attach the css and javascript necessary for layout there... of course, this seems so obvious notionally, that I am suspicious that the feature must already be there inherent in the weblocks design and I just don't know where it is or how to use it. At any rate, something like angular.js looks nearly ideal inasmuch as the theory of operation as described at http://www.angularjs.org seems already to be working toward this goal.

Kind Regards.,

Brian

[o_z]

вторник, 20 ноября 2012 г., 20:16:24 UTC+2 пользователь Brian O'Reilly написал:

Glad you liked BEM.

Second, I don't like to put templates in separate files. I like to use them like usual lisp code. You can see example here https://github.com/html/m-katya-site/blob/master/src/collections-page.lisp. You can try to code in this way.

As for "styling generic enough", this is the problem. And the problem is that design (and makup) will not itself adapt to our needs but we have to adapt to design.

To make styling generic enough it has to pass much time and we need work to be done right now. And I think when going in that way styling protocol will crystallize itself, we will better know our needs.

For "Never write html by hand again." if you remember Slava wanted not to write html but he had to write much html. And this goal as I think much further he thought. And for my development goals I often use html (with yaclml or cl-who). So if it does not mean to "write html by hand" then we will not write it with cl-mustache and cl-who/yaclml. 

So at this point I think possibility of "Never write html by hand" with weblocks at least for my projects tends to zero. In my priorities comfort in web-framework using is higher then absance of html coding and we need to go up and step by step get free from stuff like html coding (because of discomfort actually) but when going that way we should feel maximum comfort with framework.

Other problem - I don't like idea of overriding method to change some caption or to put space somewhere or to copy grid buttons (which are in bottom) to top of the grid. Overriding helps but when using weblocks widgets it is not always as elegant as lisp is. Currently to get some stuff out of widget layout we have to search for it in different widgets and it is often tricky and very difficult for newbies. Take a look at what I had to do to forbid user to add new items to grid and to delete items https://github.com/html/m-katya-site/blob/master/src/widgets/pages-grid.lisp . If I had some layout defined with cl-mustache and yaclml I would have only to remove some stuff from it for these purposes. Or I could watch layout and to see which predicate I need to override to get work done but this would be much simpler than searching this predicate through all weblocks code. So MVC is a great pattern, IMHO it does not shine well in frameworks like rails or Zend or django but shines with components and using it with components is comfortable.

So actually with stuff I'm using I want to provide flexible layout protocol (just using separate layouts for widgets) instead of styling protocol. And for the moment layouts are more important than their styles.

As for angular.js I liked idea, it must be great for some applications and must be better than usual "frameworks mvc" but I didn't use it.

I hope this explains something and things become clearer. Would be glad to read some feedback now.

Kind Regards.,

Brian