WebHelpers plans
Mike Orr
WebHelpers. A preliminary API proposal is here:
http://wiki.pylonshq.com/display/pylonsprojects/WebHelpers+ideas .
The main goals are:
* Consolidate the 21 submodules into a much smaller number.
* Fix the bugs, inefficiencies, and unpythonic Rails'isms in the
functions. Consider each function for API improvement or elimination.
* Replace the paginator with Christoph Haas' improved one.
* Convert the HTML-generation functions to use ElementTree. These
can be used by Genshi directly but will need a new default filter for
Mako. These will probably be moved from webhelpers.rails.* to
webhelpers.html.
* Add support for more Javascript libraries, and write a common
function interface they should all provide.
The plan includes deprecating the 'rails' subpackage and some other
things, and providing equivalent functionality in other submodules.
Depending on the API we ultimately decide, this may or may not have a
significant impact on user code. Currently the 'webhelpers' module
"import *"''s everything in 'rails', which are exposed as 'h' in
controllers and templates via 'myapp.lib.helpers'. We will probably
continue this for the most-used functions, but lesser-used ones may
require dotted access or explicit imports.
The old functions will be available but deprecated in Pylons 0.9.7
(spring 2008), and eliminated in Pylons 1.0 (summer/fall). The API is
not fixed yet and there's no reference implementation, so you'll have
to continue using the existing WebHelpers functions for now.
Feedback questions:
* Which parts of WebHelpers do you use besides url_for and the form tags?
* Do you use the 'hinclude', 'htmlgen', 'textile', or
'compress_resources' helpers?
* There are three text-to-HTML helpers: 'htmlgen', 'textile',
'markdown'. Do we need all of these or can we standardize on one? Do
they even need to be in WebHelpers at all? The user could import them
separately.
* 'simple_format' in 'webhelpers.rails.text' does your basic "text
paragraphs to <p> and single newlines to <br>" formatting. But
displaying untrusted text requires more formatting than this,
especially escapling/removing disallowed tags. Should we replace
'simple_formatting' with something more sophistocated, and if so,
what?
* Are you satisfied with Scriptaculous/Prototype? Which other
Javascript libraries would you like to see in WebHelpers. Do you use
any of the 'webhelpers.rails.prototype' functions besides
'link_to_remote'? Ben wants to replace 'link_to_remote' with a
function that has more client-side-Javascript, to avoid the
inefficient eval of the JSON result. Are there any other functions
which would be useful?
'url_for' will likely be changing to a smarter 'url' object, and moved
out of WebHelpers. More info soon.
You can provide feedback in this thread and/or on the wiki page.
Please put anything complicated or super-important in the wiki, so it
doesn't slip through the cracks.
--
Mike Orr <slugg...@gmail.com>
Max Ischenko
Over the weekend Ben and I and others developed a plan to overhaul
WebHelpers. A preliminary API proposal is here:
http://wiki.pylonshq.com/display/pylonsprojects/WebHelpers+ideas .
The main goals are:
Sounds nice.
The old functions will be available but deprecated in Pylons 0.9.7
(spring 2008), and eliminated in Pylons 1.0 (summer/fall). The API is
not fixed yet and there's no reference implementation, so you'll have
to continue using the existing WebHelpers functions for now.
Feedback questions:
* Which parts of WebHelpers do you use besides url_for and the form tags?
I use url_for plus form tags. That's all.
Only now, reading your feedback questions I realied webhelpers contained a lot more. ;)
'url_for' will likely be changing to a smarter 'url' object, and moved
out of WebHelpers. More info soon.
changing names, again? Pls don't do that. It's so much easier to grep for url_for symbol when, say, you need to update your routing rules. "url" is much worse.
+1 for moving it into Pylons core.
As for the rest of cruft, TG2 seems like a natural place for it, since it is "batteries included" framework, as opposed to "minimalistic Pylons". No?
Devin Torres
> * There are three text-to-HTML helpers: 'htmlgen', 'textile',
> 'markdown'. Do we need all of these or can we standardize on one? Do
> they even need to be in WebHelpers at all? The user could import them
> separately.
> * Are you satisfied with Scriptaculous/Prototype? Which other
> Javascript libraries would you like to see in WebHelpers. Do you use
> any of the 'webhelpers.rails.prototype' functions besides
> 'link_to_remote'? Ben wants to replace 'link_to_remote' with a
> function that has more client-side-Javascript, to avoid the
> inefficient eval of the JSON result. Are there any other functions
> which would be useful?
Devin Torres
Ian Bicking
> * Convert the HTML-generation functions to use ElementTree. These
> can be used by Genshi directly but will need a new default filter for
> Mako. These will probably be moved from webhelpers.rails.* to
> webhelpers.html.
Doesn't only the dev version of ET has an HTML serializer? Obviously
that's important.
I would like if the objects also had a nice __str__, and ET object have
a lousy __str__. The objects can be extended, though, if we want to
improve some of these things.
> * Do you use the 'hinclude', 'htmlgen', 'textile', or
> 'compress_resources' helpers?
compress_resources is a distutils extension, not a helper. Different scope.
> * There are three text-to-HTML helpers: 'htmlgen', 'textile',
> 'markdown'. Do we need all of these or can we standardize on one? Do
> they even need to be in WebHelpers at all? The user could import them
> separately.
On criteria might be if they wrap the respective libraries well
(especially textile and markdown), if they expose enough, and if they
have real value over the underlying libraries (e.g., a unified interface).
> * 'simple_format' in 'webhelpers.rails.text' does your basic "text
> paragraphs to <p> and single newlines to <br>" formatting. But
> displaying untrusted text requires more formatting than this,
> especially escapling/removing disallowed tags. Should we replace
> 'simple_formatting' with something more sophistocated, and if so,
> what?
lxml.html.clean does cleaning. And it's fairly complicated (though the
tests could be reused elsewhere). lxml is relatively harder to install
than other pure-python libraries (harder than a simple C extension too
as it uses a library, libxml2, usually provided by the system. And
because Macs are annoying.)
In theory translating stuff from lxml to ET wouldn't be that hard,
except that's just the theory. This particular code makes use of XPath
quite a bit, and the parent pointer that lxml has and ET does not.
I think it's a really handy thing to have around, but it's just not easy.
Maybe translating to BeautifulSoup would be easier. Or maybe we can
figure out a way to make lxml eggs that are more reliable (e.g.,
statically compiled).
> 'url_for' will likely be changing to a smarter 'url' object, and moved
> out of WebHelpers. More info soon.
After doing an application example with WebOb I've found the various
*url properties on requests a bit annoying. I don't plan to get rid of
them, but it would be nice if there was also a richer url object that
encompassed more general URL manipulation.
This won't be the same as url_for, which is tied to Routes, but ideally
it would have some API overlap. I haven't really thought about what it
would look like.
--
Ian Bicking : ia...@colorstudy.com : http://blog.ianbicking.org
Mike Orr
>
> Mike Orr wrote:
> > * Convert the HTML-generation functions to use ElementTree. These
> > can be used by Genshi directly but will need a new default filter for
> > Mako. These will probably be moved from webhelpers.rails.* to
> > webhelpers.html.
>
> Doesn't only the dev version of ET has an HTML serializer? Obviously
> that's important.
>
> I would like if the objects also had a nice __str__, and ET object have
> a lousy __str__. The objects can be extended, though, if we want to
> improve some of these things.
I remember another XML serializer that was more pythonic than
ElementTree, though I can't remember which one it was.
> > * 'simple_format' in 'webhelpers.rails.text' does your basic "text
> > paragraphs to <p> and single newlines to <br>" formatting. But
> > displaying untrusted text requires more formatting than this,
> > especially escapling/removing disallowed tags. Should we replace
> > 'simple_formatting' with something more sophistocated, and if so,
> > what?
>
> lxml.html.clean does cleaning. And it's fairly complicated (though the
> tests could be reused elsewhere). lxml is relatively harder to install
> than other pure-python libraries (harder than a simple C extension too
> as it uses a library, libxml2, usually provided by the system. And
> because Macs are annoying.)
>
> In theory translating stuff from lxml to ET wouldn't be that hard,
> except that's just the theory. This particular code makes use of XPath
> quite a bit, and the parent pointer that lxml has and ET does not.
>
> I think it's a really handy thing to have around, but it's just not easy.
>
> Maybe translating to BeautifulSoup would be easier. Or maybe we can
> figure out a way to make lxml eggs that are more reliable (e.g.,
> statically compiled).
I don't want to add anything that depends on C libraries. That just
makes things a hassle to install (Windows doesn't come with a
compiler; Mac puts things in nonstandard locations). Which makes a
percentage of users choose something else instead.
> > 'url_for' will likely be changing to a smarter 'url' object, and moved
> > out of WebHelpers. More info soon.
>
> After doing an application example with WebOb I've found the various
> *url properties on requests a bit annoying. I don't plan to get rid of
> them, but it would be nice if there was also a richer url object that
> encompassed more general URL manipulation.
>
> This won't be the same as url_for, which is tied to Routes, but ideally
> it would have some API overlap. I haven't really thought about what it
> would look like.
url_for could be implemented on top of something. Of course there's
always the need to parse and assemble URLs, which can be put in a
class. What we're considering is an object with route-generation
methods:
url_for.home() # A named route.
url_for.blog(id=1234) # Another named route.
url_for(controller="foo", action="dig")
# Use the default route (:controller/:action/:id)
url_for.current(page=2) # Derive a URL from the current page.
url_for.current("faq/") # Possibly a urljoin from the current page.
--
Mike Orr <slugg...@gmail.com>
iain duncan
One caveat that I just hit: I love everything about jQuery except signal
handling. Their signal handling does not work consistently across all
browsers. In this regard MochiKit is IMHO still the best. I've wound up
using jQuery for most things, and Mochi.Signal.
Iain
bruno.des...@gmail.com
On 8 jan, 21:05, "Devin Torres" <devin.tor...@gmail.com> wrote:
> On Monday 07 January 2008 14:35:12 Mike Orr wrote:>
> > Javascript libraries would you like to see in WebHelpers. Do you use
> > any of the 'webhelpers.rails.prototype' functions besides
> > 'link_to_remote'? Ben wants to replace 'link_to_remote' with a
> > function that has more client-side-Javascript, to avoid the
> > inefficient eval of the JSON result. Are there any other functions
> > which would be useful?
>
> jQuery. Nobody uses Prototype or Scriptaculous anymore, jQuery's simplicity
> fits in well with Pylons, and I find jQuery more Pythonic than even
> Mochikit.
scriptaculous and jQuery on two recent projects, I *highly* recommend
jQuery. Anyway, I don't like this "link_to_remote" stuff since I try
my best to make my js unobtrusive.
My 2 cents...
Dan Scott
<snip>
* Are you satisfied with Scriptaculous/Prototype? Which other
Javascript libraries would you like to see in WebHelpers.
</snip>
I've only very recently using Pylons, so much of this is new to me. I was surprised, however, that no other poster has mentioned Dojo ( http://dojotoolkit.org/) so far as a Javascript library; of interest. One of the projects that I'm contributing to (Evergreen, at http://open-ils.org/ ) recently chose Dojo as their standard Javascript library for future development of Web-based UIs, and as we're trying out Pylons for a new component it would be nice to have some built-in integration with Dojo that we could take advantage of.
Of course, if wishes were horses, we'd have a whole lot of pet food. Or something like that.
--
Dan Scott
Laurentian University
m h
> On 07/01/2008, Mike Orr <slugg...@gmail.com> wrote:
> <snip>
>
> >
> >
> > * Are you satisfied with Scriptaculous/Prototype? Which other
> > Javascript libraries would you like to see in WebHelpers.
>
> </snip>
>
> I've only very recently using Pylons, so much of this is new to me. I was
> surprised, however, that no other poster has mentioned Dojo (
> http://dojotoolkit.org/) so far as a Javascript library; of interest. One of
> the projects that I'm contributing to (Evergreen, at http://open-ils.org/ )
> recently chose Dojo as their standard Javascript library for future
> development of Web-based UIs, and as we're trying out Pylons for a new
> component it would be nice to have some built-in integration with Dojo that
> we could take advantage of.
I've used pylons with dojo and yui just fine. (The jsonify decorator
is your friend) What kind of integration do you want?
cheers,
-matt
Ian Bicking
>> This won't be the same as url_for, which is tied to Routes, but ideally
>> it would have some API overlap. I haven't really thought about what it
>> would look like.
>
> url_for could be implemented on top of something. Of course there's
> always the need to parse and assemble URLs, which can be put in a
> class. What we're considering is an object with route-generation
> methods:
>
> url_for.home() # A named route.
> url_for.blog(id=1234) # Another named route.
> url_for(controller="foo", action="dig")
> # Use the default route (:controller/:action/:id)
> url_for.current(page=2) # Derive a URL from the current page.
> url_for.current("faq/") # Possibly a urljoin from the current page.
Hmm... I don't think WebOb could do anything that looks like this. If I
add something to WebOb I think it's going to look pretty different, so
no need to try to keep them similar.
gasolin
> > fits in well with Pylons, and I find jQuery more Pythonic than even
> > Mochikit.
>
> I haven't used Mochikit so far, but having used both prototype/
> scriptaculous and jQuery on two recent projects, I *highly* recommend
> jQuery. Anyway, I don't like this "link_to_remote" stuff since I try
> my best to make my js unobtrusive.
>
I've made jquery widget for TG and some 'link_to_remote/
periodically_call_remote/form_remote_tag' widgets to more pythonic
convention (twisted naming style) as 'addCallback/addPeriodBack/
addFormback'.
http://pypi.python.org/pypi/jquery
BTW, jquery has Ext-equivalent UI plugins as well.
http://ui.jquery.com/
--
Fred
Mike Orr
including MochiKit which wasn't mentioned initially. JQuery seems to
get the most votes. However, we still haven't decided so keep the
feedback coming.
One critical factor is maintainers. We'll need a maintainer for each
Javascript library that is added. So the best way to get a Javascript
library included is to volunteer to maintain it.
There hasn't been much feedback about the rest of WebHelpers. Does
that mean I can change anything at all and y'all won't find it too
burdensome to change your apps?
--
Mike Orr <slugg...@gmail.com>
Justin Driscoll
- Justin
Mike Orr
HTML generation:
- It outputs only XHTML, not HTML.
- You can't call str() on an element and get the serialized version,
you have to call .write(). While a Mako filter can be taught to do
that, it makes it less usable in other contexts.
One solution would be to make a wrapper that serializes on str(), and
just live with XHTML even if the page is HTML.
I looked at BeautifulSoup, but it's really a parsing/query tool than a
generator. There's only one serializing method, and who knows how it
decides whether to output <br /> or <br>.
Or we could write our own dual-mode serializer.
Or use Genshi, which outputs both XHTML and HTML. But Genshi requires
a complete XM document for input , and we're just generating snippets.
Or borrow the serializing code from Genshi and use it with ElementTree.
Or use one of the stan/nevow/breve type generators.
doc = T.div[
T.h1['Section ', results['secnum']],
T.p['Elements of type ', results['type'],
' should be coloured ', results['color']],
T.p['Contributed by: ', results['user']],
]
Any better ideas? Is there a tokenizing XHTML/HTML generator that's
pythonic and doesn't depend on C libraries?
--
Mike Orr <slugg...@gmail.com>
Max Ischenko
Ben discovered two problems with using ElementTree for the WebHelpers
HTML generation:
...
Any better ideas? Is there a tokenizing XHTML/HTML generator that's
pythonic and doesn't depend on C libraries?
I must have missed it but why do you need one?
Max.
Robert Leftwich
On Thu, 10 Jan 2008 09:38:56 -0800, "Mike Orr" <slugg...@gmail.com>
said:
>
> I see Pylons users have several favorite Javascript libraries,
I use and recommend YUI, but still have some code that uses the original
WebHelpers/prototype.js.
> One critical factor is maintainers. We'll need a maintainer for each
> Javascript library that is added. So the best way to get a Javascript
> library included is to volunteer to maintain it.
I'll put my hand up to maintain the YUI library.
> There hasn't been much feedback about the rest of WebHelpers. Does
> that mean I can change anything at all and y'all won't find it too
> burdensome to change your apps?
marketshares is a big codebase - there is no doubt that there will be
some changes that will require extensive rework.
I use the following WebHelpers:
check_box
evaluate_remote_response
form_remote_tag
form
hidden_field
link_to
number_with_precision
password_field
select
submit
submit_to_remote
text_field
truncate
update_element_function
and have YUI variations of :
form_remote_tag
link_to_remote
options_for_ajax
observe_form
remote_function
update_element_function
Note that these include only the minimum implementation required for my
needs.
Robert
Lawrence Oluyede
>
> Ben discovered two problems with using ElementTree for the WebHelpers
> HTML generation:
What about http://codespeak.net/lxml/dev/lxmlhtml.html#creating-html-with-the-e-factory
?
About the JavaScript thing: is it savvy to havea "one for all"
dependency with one of the gazillion libraries out there?
--
Lawrence, stacktrace.it - oluyede.org - neropercaso.it
"It is difficult to get a man to understand
something when his salary depends on not
understanding it" - Upton Sinclair
Mike Orr
> marketshares is a big codebase - there is no doubt that there will be
> some changes that will require extensive rework.
>
> I use the following WebHelpers:
Here's an interesting point. Robert could keep his app tied to the
current version of WebHelpers *if* Pylons didn't depend on a different
version.
Does Pylons need WebHelpers other than to import into
myapp.lib.helpers? Maybe they should be decoupled. Especially if
url_for moves out of WebHelpers.
--
Mike Orr <slugg...@gmail.com>
Mike Orr
>
> On Jan 11, 2008 9:42 AM, Mike Orr <slugg...@gmail.com> wrote:
> >
> > Ben discovered two problems with using ElementTree for the WebHelpers
> > HTML generation:
>
> What about http://codespeak.net/lxml/dev/lxmlhtml.html#creating-html-with-the-e-factory
> ?
>
> About the JavaScript thing: is it savvy to havea "one for all"
> dependency with one of the gazillion libraries out there?
That's an issue. But Pylons should have good Javascript support out
of the box. The question is how to accomplish this. If there were
one obviously best Javascript library, we'd use that, but each one
seems to have different advantages.
The only disadvantage of ExtJS I've heard is that it's so big, not
that it's missing anything. So that's an advattage. Does it have
good modularity; i.e., is it possible to load just the parts you use?
--
Mike Orr <slugg...@gmail.com>
Mike Orr
To generate the HTML in a more systematic manner than just filling
strings, and guarantee it's well
formed. To squash some bugs where things sometimes get
double-escaped, by keeping escapable and non-escapable chunks
distinct.
--
Mike Orr <slugg...@gmail.com>
Lawrence Oluyede
> that it's missing anything. So that's an advattage. Does it have
> good modularity; i.e., is it possible to load just the parts you use?
extjs is quite modular: http://extjs.com/download/build
try to build a version without an adapter
Mike Orr
> >
> > Ben discovered two problems with using ElementTree for the WebHelpers
> > HTML generation:
>
> What about http://codespeak.net/lxml/dev/lxmlhtml.html#creating-html-with-the-e-factory
> ?
Yeah, lxml was mentioned before. But it depends on a C library, which
makes it a hassle to install on some systems. Windows doesn't come
with a compiler, and Macintosh doesn't have a proper package manager
and installs things to nonstandard locations. I don't want Pylons to
be so hard to install that people choose other frameworks instead.
--
Mike Orr <slugg...@gmail.com>
Christoph Haas
Ben suggested trying ExtJS to me because the basic functionality of
ExtJS is close to that of jQuery. So I tried it and am pretty impressed
indeed. The raw powers of ExtJS are definitely the complex widgets. I
have never before seen an inline-editable grid with server-side sorting
and an AJAJ (AJAX with JSON instead of XML) paginator.
I see two problems though:
- ExtJS (all of it) is 500 KB large. At least Firefox, Konqueror and
Opera load that pretty fast. But Firebug (a debugger addon for
Firefox) has a lot of trouble with that and only a hacked version
runs half decently.
- You will write your application in 90% Javascript and 10% Pylons.
ExtJS just uses a backend like Pylons to exchange JSON information
for typical CRUD operations. You can't just use formencode with
htmlfill to validate your forms because you do not send HTML to
the browser. So you have to do some other kind of validation and
add Javascript for error handling. Don't get me started on that
ugly "for" loops in Javascript. I hoped I'd never again have to
see them since I dumped C.
So, yes, ExtJS is mighty but for most applications it's too 2.0-ish.
ExtJS applications don't degrade at all. Although their developers made
great efforts in making the CSS and HTML good enough to work in all
browsers I could try (Firefox 2, Konqueror, Opera 9, IE 7) it's pure
bloat. Sure it's functional and I don't want to re-invent all those
wheels. But take a look at the default CSS: ~850 classes. And a normal
grid is a ten-level-deep monster of DIVs and TABLEs. Not sure I'll
finish my current project with ExtJS instead of jQuery.
</my 2¢>
Christoph
--
em...@christoph-haas.de www.workaround.org JID: chr...@jabber.workaround.org
gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586
Ian Bicking
Ian Bicking
When sending form data via JSON, wouldn't you just send the same values
that you'd pass to htmlfill? That is, extjs does the form filling, so
you don't need htmlfill for it.
It would require some extra infrastructure, but it also seems like you
should be able to accept the form data and run validators on it, then
return error messages in json, if you want incremental error messages.
Some sort of infrastructure for Javascript validation using FormEncode
schemas would be good, with or without extjs.
Christoph Haas
> Christoph Haas wrote:
> > Ben suggested trying ExtJS to me because the basic functionality of
> > ExtJS is close to that of jQuery. So I tried it and am pretty impressed
> > indeed. The raw powers of ExtJS are definitely the complex widgets. I
> > have never before seen an inline-editable grid with server-side sorting
> > and an AJAJ (AJAX with JSON instead of XML) paginator.
> >
> > I see two problems though:
> >
> > - ExtJS (all of it) is 500 KB large. At least Firefox, Konqueror and
> > Opera load that pretty fast. But Firebug (a debugger addon for
> > Firefox) has a lot of trouble with that and only a hacked version
> > runs half decently.
> > - You will write your application in 90% Javascript and 10% Pylons.
> > ExtJS just uses a backend like Pylons to exchange JSON information
> > for typical CRUD operations. You can't just use formencode with
> > htmlfill to validate your forms because you do not send HTML to
> > the browser. So you have to do some other kind of validation and
> > add Javascript for error handling. Don't get me started on that
> > ugly "for" loops in Javascript. I hoped I'd never again have to
> > see them since I dumped C.
>
> When sending form data via JSON, wouldn't you just send the same values
> that you'd pass to htmlfill? That is, extjs does the form filling, so
> you don't need htmlfill for it.
Agreed. The htmlfill component is not needed here.
> It would require some extra infrastructure, but it also seems like you
> should be able to accept the form data and run validators on it, then
> return error messages in json, if you want incremental error messages.
> Some sort of infrastructure for Javascript validation using FormEncode
> schemas would be good, with or without extjs.
Can you imagine how one can use formencode validation to validate an
ExtJS form? I'm not that far actually in my test application so I'm not
sure whether they run a POST or serialize the fields in a GET request.
But if I could continue to use my schemas in ExtJS context with little
pain that'll be great.
Cheers
Ian Bicking
>> It would require some extra infrastructure, but it also seems like you
>> should be able to accept the form data and run validators on it, then
>> return error messages in json, if you want incremental error messages.
>> Some sort of infrastructure for Javascript validation using FormEncode
>> schemas would be good, with or without extjs.
>
> Can you imagine how one can use formencode validation to validate an
> ExtJS form? I'm not that far actually in my test application so I'm not
> sure whether they run a POST or serialize the fields in a GET request.
> But if I could continue to use my schemas in ExtJS context with little
> pain that'll be great.
Well, if they do a complete POST or submit a JSON request, it doesn't
matter too much I think.
You'd get the values in some way (json decode or request.params), and
then do:
try:
result = schema(ignore_key_missing=True).to_python(fields)
errors = None
except Invalid, e:
errors = e.unpack_errors()
return Response(simplejson.dumps(errors))
Mayowa
but i want to program in python not javascript, and when i need to do
javascript, jQuery lets me do
what i need quickly and get right back to my python/pylons.
On Jan 11, 5:15 pm, Christoph Haas <em...@christoph-haas.de> wrote:
> On Fri, Jan 11, 2008 at 05:51:00AM -0800, Mike Orr wrote:
> > > What abouthttp://codespeak.net/lxml/dev/lxmlhtml.html#creating-html-with-the-e-...
Marek Stępniowski
--
Marek Stępniowski
email: m.step...@gmail.com || m.step...@students.mimuw.edu.pl
gg: 5354504
ru...@decrop.net
months (first version 1, later version 2). I have a mixed experience
- It has full feature set of widgets
- It looks very nice but is bloated in many ways
- Due to its size you need a lot of bandwidth on the server
- It is slow to use. Opening a dialog box once a page is loaded, is
very slow compared to hand made javascript. It becomes even annoying
on 3 years old PCs;
- extjs uses tons of css style sheets classes linked to all the
widgets. Sadly enough these style sheet classes are not documented.
Either you use the predefined styles, or you have hours work to do
some modifications
The biggest complaint I have and the main reason to stop using it is
the development process. You have to write a lot of error prone
javascript to tie together all the widgets; This can only be debugged
using long firebug sessions. I was hoping that after the initial
learning curve, the development would speed up, but that is not the
case
Ruben
Lawrence Oluyede
> the development process. You have to write a lot of error prone
> javascript to tie together all the widgets; This can only be debugged
> using long firebug sessions. I was hoping that after the initial
> learning curve, the development would speed up, but that is not the
> case
It seems that the complexity overcame the reason why extjs exists.
BTW extjs is too big to be included in pylons and does a hell lot more
than the standard developer needs (which is basically dom
manipulation, css selectors and Ajax).
Am I right?
Mike Orr
> It seems that the complexity overcame the reason why extjs exists.
> BTW extjs is too big to be included in pylons and does a hell lot more
> than the standard developer needs (which is basically dom
> manipulation, css selectors and Ajax).
> Am I right?
Yes. People need to update parts of a page, and some want colorful
special effects, the more the better.
Also, some Javscripts make JS more like Python, which helps in programming it.
Well, JQuery is by far the most popular on the list, and moderately
more popular in the wiki poll, so let's assume we'll be adding it
alongside Prototype/Scriptaculous. We'll need a maintainer to package
it up for WebHelpers, and also to help decide the common Python
interface to all these libraries.
Are there any important features not in JQuery that we should have?
Robert Leftwich offered to maintain YUI. It has some popularity among
Pylons users so we might as well.
Let's have the JS maintainers and those who wish to help design the
Pylons Javascript API subscribe to pylons-devel, and we can discuss it
there.
http://groups.google.com/group/pylons-devel
There was a glowing recommendation for Dojo, but it will need a
maintainer if it's to be included.
ExtJS can be added later if enough people clamor for it. (I think
Mark Ramm was the only person who said he likes it.) But I was struck
by Christoph Haas' comment, "[With ExtJS] you will write your
application in 90% Javascript and 10% pylons." Somebody who's writing
a 90% Javascript application probably does not need Pylons, just a
static webserver and something for database queries.
--
Mike Orr <slugg...@gmail.com>
Christoph Haas
> On Jan 14, 2008 4:57 AM, Lawrence Oluyede <l.ol...@gmail.com> wrote:
>
> > It seems that the complexity overcame the reason why extjs exists.
> > BTW extjs is too big to be included in pylons and does a hell lot more
> > than the standard developer needs (which is basically dom
> > manipulation, css selectors and Ajax).
> > Am I right?
>
> Yes. People need to update parts of a page, and some want colorful
> special effects, the more the better.
> Also, some Javscripts make JS more like Python, which helps in programming it.
>
> Well, JQuery is by far the most popular on the list, and moderately
> more popular in the wiki poll, so let's assume we'll be adding it
> alongside Prototype/Scriptaculous. We'll need a maintainer to package
> it up for WebHelpers, and also to help decide the common Python
> interface to all these libraries.
I think a generic interface that translates to library-specific
Javascript commands is really the best way. Let's support:
- jQuery
- YUI
- scriptaculous/prototype
If we can agree on some high-level API (I have no idea how to design
that yet) then I'll happily (co-)maintain the API-to-jQuery functions.
> Are there any important features not in JQuery that we should have?
Mainly UI elements. ui.jquery.com still has some sharp edges. But for
the colorful basics and AJAX jQuery is more than sufficient and very
light-weight and fast.
> Robert Leftwich offered to maintain YUI. It has some popularity among
> Pylons users so we might as well.
It appears like the most reasonable choice if you need a few widgets and
don't intend to surrender to ExtJS.
> Let's have the JS maintainers and those who wish to help design the
> Pylons Javascript API subscribe to pylons-devel, and we can discuss it
> there.
I'm there. Let the games begin. :)
> ExtJS can be added later if enough people clamor for it. (I think
> Mark Ramm was the only person who said he likes it.)
Ben Bangert dumped ExtJS onto me on IRC when we talked about Javascript
libraries. :) And he's right - the basic selectors are basically
identical to jQuery. But there the similarities end.
> But I was struck
> by Christoph Haas' comment, "[With ExtJS] you will write your
> application in 90% Javascript and 10% pylons." Somebody who's writing
> a 90% Javascript application probably does not need Pylons, just a
> static webserver and something for database queries.
Or even (bear with me) a few cheap PHP scripts baked together. Pylons
has so many great tools that create HTML, validate forms, support AJAX
calls, handle JSON, use sessions... it would be a shame not to use that.
Talking about it with a few people (e.g. the maintainer of the "ingrid"
grid plugin in jQuery or even newcomers in #extjs) I heard more voices
about ExtJS. Most people say that ExtJS is an impressive library and a
proof-of-concept what's possible in the web 2.0 <cough> world. But not
just does the 90%/10% relation still seem to be true but the Javascript
needed to define the widgets is a hell to look up in the API reference
and create working code from it. The learning curve is pretty flat. For
a current project where I tried it I've now dumped it and gone back to
jQuery. Looks like the makers of ExtJS have taken classic UI concepts
(event handlers control everything) and mixed them with bloat. ;)
Cheers
Ben Bangert
> Are there any important features not in JQuery that we should have?
There's the drag n drop, which ui.jquery.com is working on I believe,
and the observable thing from prototype might not be in jquery, I'm
not sure.
> Robert Leftwich offered to maintain YUI. It has some popularity among
> Pylons users so we might as well.
I should note that jQuery and YUI are not exclusive to each other, I
usually use them both at once. jQuery for lighter effects and its
selectors, but then YUI for the bigger components like autocomplete,
etc. I don't think we need a 'either X or X' with jQuery and YUI when
they work so well when used together.
> Let's have the JS maintainers and those who wish to help design the
> Pylons Javascript API subscribe to pylons-devel, and we can discuss it
> there.
> http://groups.google.com/group/pylons-devel
Yep, sounds good.
Cheers,
Ben