Since interest on Weblocks has picked up recently it's appropriate that I write about what I have in mind for it.There are my opinions after working with Weblocks for a couple of years.
Weblocks has a lot of bloat and too strong coupling in it, and also many leftovers. Much of it is just not practical.My proposals:* Create small components with their own systems, e.g. weblocks-base, weblocks-stores, weblocks-forms, weblocks-continuations...
* 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.
* 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.
* 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.
* Provide good template support.
* Get rid of the test suite. Try to write a frontend-based testing mechanism (I probably won't do this).
If anyone has any other useful ideas or is interested in helping, please chime in. Thanks!
On Sun, Jul 8, 2012 at 1:04 PM, Leslie P. Polzer <leslie...@gmx.net> wrote:Since interest on Weblocks has picked up recently it's appropriate that I write about what I have in mind for it.There are my opinions after working with Weblocks for a couple of years.
Weblocks has a lot of bloat and too strong coupling in it, and also many leftovers. Much of it is just not practical.My proposals:* Create small components with their own systems, e.g. weblocks-base, weblocks-stores, weblocks-forms, weblocks-continuations...
I don't object to this, but I don't think it's very important. Sure, there's lots of stuff in the current Weblocks that I'm not using, and I suppose I could care about the memory consumed by these components, but I'm sure it's minuscule by modern standards. (There are lots of other Quicklisp systems that are being loaded as dependencies, and I'm not even sure I'm actually using all of them. This is where I'd start if I were so concerned about image size.)
* 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.
I'm not familiar with these issues since I'm happy using the CLSQL store.
* 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.
I like using flows. I've used a number of small flows in BountyOSS. I admit, it took me a while to be completely comfortable with them, but I am now and wouldn't want to lose them. I think some of the difficulty could be avoided with better documentation. I'll write more about this soon.
* Provide sane versions of dataform and gridedit that don't depend on stores and are easily customizable. I already have a good dataform substitute.
I haven't yet had a chance to study form-widget, but dataform has done everything I've wanted so far.
* Get rid of Prototype and Scriptaculous in favor of JQuery.
This, I think, would be a huge improvement. I have to qualify this a little because I haven't looked closely at what Prototype and Scriptaculous are capable of; but I see how much momentum jQuery has, including a vibrant plugin ecosystem, and it does seem to be the way to go.
* Provide good template support.
Huh, that's a surprise. I thought one of the best things about Weblocks was that it doesn't use templates. Anyway, there's already 'with-html' -- what more does anyone need?
* Get rid of the test suite. Try to write a frontend-based testing mechanism (I probably won't do this).
A frontend-based testing mechanism would be particularly great if it could be easily adapted to testing sites. I haven't done anything about automated testing for BountyOSS, but I will obviously need to at some point. (I don't think it's my biggest problem quite yet, but it's looming larger.)
If anyone has any other useful ideas or is interested in helping, please chime in. Thanks!
I have more little features and bug fixes in my GitHub fork. i'll be sending more pull requests soon.
I think that if Weblocks is to become more popular, its most urgent need is much better documentation. Maybe I can help with this at some point... not that I have much time.
-- Scott
--
You received this message because you are subscribed to the Google Groups "weblocks" group.To post to this group, send email to webl...@googlegroups.com.
To unsubscribe from this group, send email to weblocks+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
2012/7/9 Scott L. Burson <Sc...@ergy.com>On Sun, Jul 8, 2012 at 1:04 PM, Leslie P. Polzer <leslie...@gmx.net> wrote:* Get rid of Prototype and Scriptaculous in favor of JQuery.
This, I think, would be a huge improvement. I have to qualify this a little because I haven't looked closely at what Prototype and Scriptaculous are capable of; but I see how much momentum jQuery has, including a vibrant plugin ecosystem, and it does seem to be the way to go.
Here is my developments of it, core system works with replacement of this small library. Probably some widgets don't work with it.
> weblocks+unsubscribe@googlegroups.com.
Since interest on Weblocks has picked up recently it's appropriate that I write about what I have in mind for it.
My proposals:* Create small components with their own systems, e.g. weblocks-base, weblocks-stores, weblocks-forms, weblocks-continuations...
* 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.
* 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.
* 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.
* Move version control to git and the repository to Github
* Provide a mechanism of generating CSS automatically.* Provide good template support.
If anyone has any other useful ideas or is interested in helping, please chime in. Thanks!
I was never able to get mixins to work reliably.
They could use some love--they're a really big piece of any non-trivial application.
Since interest on Weblocks has picked up recently it's appropriate that I write about what I have in mind for it.There are my opinions after working with Weblocks for a couple of years.Weblocks has a lot of bloat and too strong coupling in it, and also many leftovers. Much of it is just not practical.My proposals:* Create small components with their own systems, e.g. weblocks-base, weblocks-stores, weblocks-forms, weblocks-continuations...
* 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.* 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.* 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.
* Move version control to git and the repository to Github* 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).
Sounds very good! Thanks for your work! :)
--
You received this message because you are subscribed to the Google Groups "weblocks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weblocks+u...@googlegroups.com.
To post to this group, send email to webl...@googlegroups.com.
Visit this group at http://groups.google.com/group/weblocks.
Have you noticed www.happstack.com??
The thing that is amazing is the data store acid-state.
It is similar to www.prevayler.org or cl-prevalence
I think if a lisp web framework integrated well with cl-prevalence it would be just awesome.
I know from talking to some programmers that component based web layout creation seems to beat basic templates, and I notice perls mason is popular for that and that in the microsoft world the IIS .net MVC tools also do "compontent based" not just template.
I don't have much knowhow to do what you do and I admire your amazing work.