On Jan 14, 2008, at 8:35 AM, Mike Orr wrote:
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
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
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
On Jan 14, 2008 4:57 AM, Lawrence Oluyede [EMAIL PROTECTED] 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
I'm also +1 for JQuery.
--
Marek Stępniowski
email: [EMAIL PROTECTED] || [EMAIL PROTECTED]
gg: 5354504
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to
+1 for JQuery,
- You will write your application in 90% Javascript and 10% Pylons.
I couldn't have said it any better. There are things i love about Ext,
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
On Jan 11, 2008 10:42 AM, Mike Orr [EMAIL PROTECTED] wrote:
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
On Jan 11, 2008 9:42 AM, Mike Orr [EMAIL PROTECTED] 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
On Jan 11, 2008 3:41 AM, Robert Leftwich [EMAIL PROTECTED] wrote:
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
On Jan 11, 2008 4:48 AM, Lawrence Oluyede [EMAIL PROTECTED] wrote:
On Jan 11, 2008 9:42 AM, Mike Orr [EMAIL PROTECTED] wrote:
Ben discovered two problems with using ElementTree for the WebHelpers
HTML generation:
What about
Christoph Haas wrote:
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
Christoph Haas wrote:
On Fri, Jan 11, 2008 at 05:51:00AM -0800, Mike Orr wrote:
On Jan 11, 2008 4:48 AM, Lawrence Oluyede [EMAIL PROTECTED] wrote:
What about
http://codespeak.net/lxml/dev/lxmlhtml.html#creating-html-with-the-e-factory
?
About the JavaScript thing: is it savvy to havea
Mike Orr wrote:
On Jan 11, 2008 4:48 AM, Lawrence Oluyede [EMAIL PROTECTED] wrote:
On Jan 11, 2008 9:42 AM, Mike Orr [EMAIL PROTECTED] wrote:
Ben discovered two problems with using ElementTree for the WebHelpers
HTML generation:
What about
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?
extjs is quite modular: http://extjs.com/download/build
try to build a version without
On Fri, Jan 11, 2008 at 05:51:00AM -0800, Mike Orr wrote:
On Jan 11, 2008 4:48 AM, Lawrence Oluyede [EMAIL PROTECTED] wrote:
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
jQuery. Nobody uses Prototype or Scriptaculous anymore, jQuery's simplicity
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
I see Pylons users have several favorite Javascript libraries,
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
I'm +1 for Dojo. The base library is excellent.
- Justin
On Jan 10, 2008 12:38 PM, Mike Orr [EMAIL PROTECTED] wrote:
I see Pylons users have several favorite Javascript libraries,
including MochiKit which wasn't mentioned initially. JQuery seems to
get the most votes. However, we still
On 8 jan, 21:05, Devin Torres [EMAIL PROTECTED] wrote:
On Monday 07 January 2008 14:35:12 Mike Orr wrote:
(snip)
* 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'
On 07/01/2008, Mike Orr [EMAIL PROTECTED] 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
On Jan 9, 2008 2:01 PM, Dan Scott [EMAIL PROTECTED] wrote:
On 07/01/2008, Mike Orr [EMAIL PROTECTED] 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
Mike Orr wrote:
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,
On 1/7/08, Mike Orr [EMAIL PROTECTED] wrote:
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
On Monday 07 January 2008 14:35:12 Mike Orr wrote:
* 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.
webhelpers.rails.form_tag
Oh yeah, and you should also check out those minification web helpers that
were posted here a few days ago. They're incredibly useful. I can combine,
minify, and then cache the result of all my javascript and css only once and
serve it up during production, but have the unminified, separated files
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
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:
* Consolidate the 21 submodules into a much smaller number.
* Fix the bugs,
27 matches
Mail list logo
