Future plans

Showing 1-19 of 19 messages
Future plans Leslie P. Polzer 7/8/12 1:04 PM
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).

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

  Leslie
Re: [weblocks] Future plans Scott L. Burson 7/8/12 2:33 PM
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

Re: [weblocks] Future plans o_z 7/8/12 9:06 PM


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:
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.
Here is my developments of it, core system works with replacement of this small library. Probably some widgets don't work with it.
 
* 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.)
I used selenium in my projects. I think it would be superfluous to include  it in weblocks.

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.

Re: [weblocks] Future plans Scott L. Burson 7/10/12 9:56 PM
On Sun, Jul 8, 2012 at 9:06 PM, Олексій Замковий <olex...@gmail.com> wrote:

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.

Cool -- thanks!!  I'll give it a try soon.

-- Scott

unk...@googlegroups.com 7/27/12 8:58 AM <This message has been deleted.>
Re: Future plans Leslie P. Polzer 7/27/12 8:59 AM
Thanks for your comments!

It appears that the best way to go about my radical changes
would be a dedicated fork of Weblocks, or a project that carries
a new name and shares only its roots with Weblocks.

Some parts like a client-oriented test suite might be shared by
both projects, but in general they should be separate.

This is good for backwards compatibility as well, and the new
project doesn't have to care about that so there's all the freedom
that is needed to design and develop it.

  Leslie
Re: [weblocks] Re: Future plans linuxhooligan 7/27/12 4:34 PM
I would be in support of that idea.  This way new ideas get to be
explored without polluting the main project for those that would like
to see those ideas continue.

I would like to volunteer for the graphic design aspects of the project.

You will probably want to start the project with a standard cms of
some sort, eventually the project should eat it's own dog food.

Let me know if I can be of assistance.

R.
> --
> 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/-/avYX902pfGcJ.
Re: [weblocks] Re: Future plans o_z 7/28/12 5:45 AM
Twitter bootstrap or something similar is enough for new project  design. I think new design will be needed only for new interface elements not implemented in such theme.

суббота, 28 июля 2012 г., 2:34:45 UTC+3 пользователь linuxhooligan написал:
Re: [weblocks] Re: Future plans Slobodan Milnović 7/28/12 7:33 AM
Hi!

Since you're all getting worked up on new changes, I would like to
make an feature request.

About an year and a half ago, Brit Butler made some changes to the
postmodern store, located here -
https://bitbucket.org/redline6561/weblocks-dev/overview

These changes allowed concurrent access to the postgress database, and
I have been happily using those since then, but I haven't made an
issue of merging it to the main weblocks tree. So, I'm doing it now.

I think that Brit made an great job, and it would be a shame not to
include his improvements. There is only one modification that needs to
be made, in the postmodern/postmodern.lisp. Method class-id-slot-name
returns an list of id-slot names, because postmodern and postgress
support more than one key. Modification is simple:

(defmethod class-id-slot-name ((class dao-class))
   ;; Returns a list of the column names which compose the primary key.
   (car (dao-keys class)))

And then class-id-slot-name will return an slot name instead of list. That's it.

So, like I have said, it would be great if this change is included,
because with this postmodern has better support than is current state
in the weblocks-dev tree. It probably needs further testing, but like
I have said, for me it worked great.
Re: Future plans Brian O'Reilly 8/9/12 1:41 PM


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?
Re: Future plans Nicholas Leippe 8/13/12 12:55 PM
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.

Re: [weblocks] Re: Future plans Scott L. Burson 8/13/12 1:17 PM
On Mon, Aug 13, 2012 at 12:55 PM, Nicholas Leippe <lei...@gmail.com> wrote:
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.

I'm using them without difficulty.  Do you recall any specific problems you encountered?

-- Scott
 
Re: Future plans o_z 5/21/13 11:54 PM


воскресенье, 8 июля 2012 г., 23:04:34 UTC+3 пользователь Leslie P. Polzer написал:
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...
The next thing I would like to do with weblocks is separating weblocks-stores. 
* 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.
At this moment both libraries work ok on different apps. 
* Move version control to git and the repository to Github
* Provide a mechanism of generating CSS automatically. 
* Provide good template support.
I've spoken about this and this will be done after separation of stores from weblocks. 
* Get rid of the test suite. Try to write a frontend-based testing mechanism (I probably won't do this).
The work is started and selenium test suite grows.
I still maintain old test suite and all tests pass. I'll get rid of some tests when it will be necessary. 
Re: Future plans Leslie P. Polzer 5/22/13 4:24 AM
Sounds very good! Thanks for your work! :)

  Leslie
Re: Future plans o_z 5/22/13 7:27 AM


среда, 22 мая 2013 г., 14:24:55 UTC+3 пользователь Leslie P. Polzer написал:
Sounds very good! Thanks for your work! :)
Great, the work is started, splitting weblocks-store is in progress.
Thank you Leslie for your work, my 31 commit comparing to your 480 is too modest. 
Re: Future plans o_z 5/23/13 11:47 PM
I've separated stores code into weblocks-stores package - https://github.com/html/weblocks-stores

среда, 22 мая 2013 г., 17:27:48 UTC+3 пользователь o_z написал:
Re: Future plans johannes falcone 8/31/13 8:58 PM
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.

I work to build linux web platforms and see messes in java and .net and php..
Re: [weblocks] Re: Future plans linuxhooligan 8/31/13 11:27 PM
Someone has already done this:

https://github.com/hargettp/hh-web/wiki


--
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.

For more options, visit https://groups.google.com/groups/opt_out.

Re: Future plans o_z 9/1/13 4:20 AM


воскресенье, 1 сентября 2013 г., 6:58:24 UTC+3 пользователь johannes falcone написал:
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.
Weblocks is integrated with cl-prevalence and few other stores via single api.
weblocks-stores can be used outside of Weblocks but package needs to be more documented.

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.
Weblocks is component based. Yes, components should beat templates but there is a need in templates too.
It would be hard to add theming into Weblocks without templates. 
Currently theming is available for most Weblocks widgets and there is Weblocks theme apart from default one. 

I don't have much knowhow to do what you do and I admire your amazing work.
As for me, glad to be of service.

I work to build linux web platforms and see messes in java and .net and php..