They will fight all the time.
On Tuesday, 18 November 2014 09:12:55 UTC-6, Richard wrote:
I miss this one...
How does JForm will cohabit with Angularjs or Ractivejs?
Richard
On Mon, Nov 17, 2014 at 11:56 PM, Massimo Di Pierro
massimo.dipie...@gmail.com wrote:
In my todo list but no
I miss this one...
How does JForm will cohabit with Angularjs or Ractivejs?
Richard
On Mon, Nov 17, 2014 at 11:56 PM, Massimo Di Pierro
massimo.dipie...@gmail.com wrote:
In my todo list but no great progress yet.
On Friday, 14 November 2014 05:58:10 UTC-6, Ramos wrote:
Just checking the
In my todo list but no great progress yet.
On Friday, 14 November 2014 05:58:10 UTC-6, Ramos wrote:
Just checking the status of Jform.
Any news on it?
Regards
António
2014-09-10 2:02 GMT+01:00 Massimo Di Pierro massimo.dipie...@gmail.com:
I agree. I have not implemented but I was
Just checking the status of Jform.
Any news on it?
Regards
António
2014-09-10 2:02 GMT+01:00 Massimo Di Pierro massimo.dipie...@gmail.com:
I agree. I have not implemented but I was planning to add this feature.
On Tuesday, 9 September 2014 03:44:30 UTC-5, Leonel Câmara wrote:
This is the
This is the corresponding JS one optimized for bootstrap 3:
jform.widgets['text'] = function(field) { return
jform.tag('textarea',{'name':field.name
,'class':'form-control'})(field.value); }
Massimo that looks good, however in SQLFORM I can change the textwidget in
a very specific
I agree. I have not implemented but I was planning to add this feature.
On Tuesday, 9 September 2014 03:44:30 UTC-5, Leonel Câmara wrote:
This is the corresponding JS one optimized for bootstrap 3:
jform.widgets['text'] = function(field) { return
jform.tag('textarea',{'name':field.name
On Sunday, September 7, 2014 9:22:06 PM UTC-4, Alex wrote:
I didn't know of custom forms. Maybe it's something that wasn't available
when I started with my forms (using v2.4.6) or I just missed it.
It's been around forever.
Actually I'm doing a little bit more in my form function (e.g.
Personally I prefer python to javascript so would render server side
myself.
Keep in mind that with the new system, you won't necessarily have to write
Javascript -- the Javascript that renders the forms will be provided by the
framework.
I am thinking of those occasions where the
My limited experience thus far with iPhone 4s, iPhone 5s and iPad leads me
to believe that form generation in the browser would NOT necessarily be a
lot faster. In fact, if you compile your views and controllers beforehand,
the current SQLFORM is remarkably fast. Speed is not the reason to go
I assume Massimo meant that it is faster on the server side.
Anthony
On Monday, September 8, 2014 2:07:12 PM UTC-4, Joe Barnhart wrote:
My limited experience thus far with iPhone 4s, iPhone 5s and iPad leads me
to believe that form generation in the browser would NOT necessarily be a
lot
My experience is that it's faster on the client side too unless you have a
pretty good 3G connection (or even better 4G).
That said, the scalability and hardware savings advantage on the server
side is unquestionable. You don't have to cache pre-rendered HTML and you
finish requests quicker.
The approach is correct IMHO, not only for forms. DOM is client's matter
and by the way gives a nice level of abstraction over everchanging DOM
implementations of clients.
What eventually will be extended is the JSON dialect.
There is a little overhead in the JS machinery on the clients that
Sounds like I need to improve my JS skills.
A Plugin or a Module ? which is better for this type of thing ?
On Friday, September 5, 2014 3:56:23 PM UTC+10, Massimo Di Pierro wrote:
Please find attached a welcome4.zip with contains the following files:
controllers/default.py
With this thinking, we should not generate any HTML tag server side.
The DOM exists when there's a HTML page, not only a form.
I may missed something, but, what's the problem with server side
generated DOM? Almost every web page is generated server side.
Again, I don't see DOM generated server
forms are made of widgets and widgets are made of HTML and JS. We can
force it and continue to code these things in Python as we do now but we
up with Python code that has the only purpose that of generating HTML and
including JS code. This is why it will be cleaner if we move this
client-side
This would be the code to override all the widgets (the list widgets are
missing) for bootstrap3.
http://pastebin.com/LJzhXvnh
I know it is JS but it is really not mad and much more user friendly than
the code in sqlhtml.py.
Massimo
On Monday, 8 September 2014 23:43:31 UTC-5, Massimo Di
this sounds very interesting, definitely a nice addition. Although I hope
the current SQLFORM will not be deprecated. Usually I prefer to create my
html forms server side. I use a function to extract all form elements so I
can create my forms more flexible, maybe this is useful for others:
Alex did you just reinvent custom forms?
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the
def get_form_fields(form):
formfields = dict()
for c in form.elements('input, select, textarea'):
name = c.attributes['_id']
formfields['c_' + name] = c
for l in form.elements('label'):
name = l.attributes['_for']
formfields['l_' + name] = l
Great idea!
I think definitely web2py should be optimized towards ajax and javascript.
I do not use SQLFORM because fixing the html it generates often takes more
time than to write my own html. I think there are some improvements that
can be done to forms anyway, which can be implemented in a
On Sat, Sep 6, 2014 at 9:52 AM, Robin Manoli ramat...@gmail.com wrote:
Great idea!
I think definitely web2py should be optimized towards ajax and javascript.
I do not use SQLFORM because fixing the html it generates often takes more
time than to write my own html. I think there are some
I do not use SQLFORM because fixing the html it generates often takes more
time than to write my own html.
You can write your own completely custom HTML and still use SQLFORM on the
server side to handle validation, database I/O, and CSRF protection. I
would not give up SQLFORM just
I like the idea of a slimmed down equivalent of SQLFORM. However, I think
it should be written to permit client side rendering via js scripts, or
server side rendering in views; as such the output as json or python
object/array would be ideal.
Personally I prefer python to javascript so would
I admit I haven't looked at this files, but these are my thoughts on the
general concept, so apologies if some of these comments don't directly
reflect your exact proposal.
I like the idea of a slimmed down form generation process on the server,
and there is a trend to greater rendering on the
On Saturday, September 6, 2014 5:30:44 PM UTC-4, Ide wrote:
I like the idea of a slimmed down equivalent of SQLFORM. However, I think
it should be written to permit client side rendering via js scripts, or
server side rendering in views; as such the output as json or python
object/array
Just to clarify your answer
with form = SQLFORM(...) then {{=form}} serializes in HTML but the
corresponding objects exist even if you don't.
with form = JForm then {{=form}} only makes a div/ which JS (provided)
converts to a form. There is no server-side DOM and this make it a lot
Massimo,
Is this also faster on mobile devices?
They tend to be a little slow with JavaScript is my experience.
On Friday, September 5, 2014 7:56:23 AM UTC+2, Massimo Di Pierro wrote:
Please find attached a welcome4.zip with contains the following files:
controllers/default.py
Unless they are on good wireless connection, it should be Quint. In my
experience with mobile apps, what makes things slow is data transfers,
these forms transfer a lot less data. In fact this follows the model I
already use for all my mobile apps, transmit json for compactness, make
html in
Ok,
but when you use gzip and the html is relatively simple, the difference
between only the data and the complete html is small I would think but the
client would still need to render the thing.
On Friday, September 5, 2014 12:06:26 PM UTC+2, Leonel Câmara wrote:
Unless they are on a good
The difference should be small for gzipped but measurable (don't forget
that you can also gzip json), the reason is that theoretically the same
information could be compressed to the same size, however, the json version
really carries less information as the structure of the document in HTML
i am for it ;)
On Friday, September 5, 2014 12:56:23 AM UTC-5, Massimo Di Pierro wrote:
Please find attached a welcome4.zip with contains the following files:
controllers/default.py
views/layout.html
vides/default/index.html
modules/jform.py
static/js/jform.js
+1
On Friday, September 5, 2014 12:56:23 AM UTC-5, Massimo Di Pierro wrote:
Please find attached a welcome4.zip with contains the following files:
controllers/default.py
views/layout.html
vides/default/index.html
modules/jform.py
static/js/jform.js
static/js/jform-bootstrap2.js
32 matches
Mail list logo
