web2py.js datetime/date/time improvement

[Niphlod]

Hi all.
What if we could remove the "ugly" datetime/date/time instantiation at every "target" loaded with something more in line with every other event attached to inputs (i.e. move to event_handlers() where it is supposed to be)?
The issue until now that the calendar needs to call setup to bind its own click handlers.
Rewritten like that we just call the setup once and trigger a click on the first click, then the calendar works as always.

      doc.on('click', "input.datetime", function () {
        $(this).attr('autocomplete', 'off');
        if (!$(this).hasClass('activated')) {
          Calendar.setup({
            inputField: this,
            ifFormat: datetime_format,
            showsTime: true,
            timeFormat: "24"
          });
          $(this).addClass('activated');
          $(this).trigger("click");
        }
      });


This basically avoids attaching a calendar to every datetime/date/time entry if it's not needed and should avoid other kinds of issues where users forget to call ajax_fields after loading a fragment, or where the datetime/date/time input is hidden when the fragment/page is loaded.

on a totally unrelated note, I'm also thinking that it could be useful to have a data-date_format optionally attached to every input to force a particular datetime/date/time field. This, for example, could temporarily fix the issue in the search widget of the grid.

What do you think ?

[Massimo Di Pierro]

I like it. I do not see any problem with it.

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Niphlod]

I'll send a PR then.

[Paolo Valleri]

I started to test web2py.js a little more
So far, I haven't been able to find a clean way to disable the html text replacement made by functions such as enable/disableElement for certain A elements. How should I can do that?

Paolo

[Niphlod]

2 months later..... at least someone that tests it :-P
I think that feature is an added value for reporting to the UI what's going behind the scenes. In the "old" code, double submissions were never intercepted....at least now for long requests you inform your users that something is going on.

However, as everything else, you can override the behaviour:
- setting w2p_ajax_disable_with_message to T("submit")
- adding your own w2p_disable to your element
- overriding your own disableElement commenting the part where the value gets updated in js

[paolo....@gmail.com]

I don't want to override the ordinary method because in several case is really a nice feature, I don't need to change the 'text' too because I just need to control its behavior a little more. 

The best is to add an attribute to the A element, the disable/enable functions will check its presence/absence before replacing the text. I have several A with particular shape and in these cases, the current approach of replacing the working/loading text doesn't fit well.

A second feature, w2p_ajax_disable_with_message right now is string, the best would be to have the possibility to call a js function name, that function will be called when an element is disabled. 

I have other idea/requests but I have to test them a little more :-P

 Paolo

2013/9/5 Niphlod <nip...@gmail.com>

You received this message because you are subscribed to a topic in the Google Groups "web2py-developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web2py-developers/29X0rqMc244/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web2py-develop...@googlegroups.com.

[Niphlod]

/me still thinks that at this stage for "I want to do it my way" the best way to go is editing web2py.js.
Let me do a quick overview (I don't think I told explicitely to anyone what the "new" web2py.js enables, BTW, I'm curious about the CHANGELOG for all things we added in the last month to web2py too):
The version shipped with 2.6.0 is meant as a base-start for lots of other features (on top of my head: form submissions via ajax in web2py right now just suck if you want to control them with js, flash messages not "categorized" by default (info, error, success, etc), inline-editing is something that we should eventually reach, etc).
Yet this is a major overhaul compared to the previous code, that enabled lots of things that were previously  unreachable/real hard to code/override.... again, on top of my head
- lots of inline javascript injected with widgets are gone (did you look at the previously generated markup for the grid vs the one right now. Did you try to alter an onclick injected fixed js function ?! :D)
- remove the need to use JQuery() instead of $ throughout all web2py code, 'cause now web2py.js is following the "anonymous function" paradigm
- easily override the behaviour just acting on the $.web2py namespace
- preventing double submissions
- make your own flash animations
- make your own errors animations
- handle your own confirm()
- creating A() and components can be done more easier with just js thanks to the data- adoption
- everything is handled by ajax_page(), so the behaviour is the same
- hooking up to ajax events (and eventually prevent them to fire in an easy way)
- A(....delete) works as intended instead of removing always the element even if the ajax request failed, and works for any element, not just the closest
- easily replace default js validators

We managed to add all of this without breaking backward compatibility.
This opens to lots of flexibility in the future (for example, one could rewrite the entire thing using another library than jquery!).
Please remember that we want to enable nice features that work for the 95% of the peoples.
The skilled 5% can still do whatever they want just overriding (as they did until now) :-P
Hopefully, the 5% can adopt part of "new" and rewrite smaller parts than before, and that's why there are boatloads of functions, each one with their own purpose. Adopting jquery-ujs as a boilerplate was a smart move to avoid errors that other very intelligent and smart guys faced before.
This unfortunately opens up to leaving most of the code in web2py.js marked as "experimental" (meaning things will not break in 2 days, but lots is going to be refactored/tuned/improved in the long run). Yet the structure is kinda predisposed in a logic way that **shouldn't** require big changes.
This was accepted as long as the documented js functions remained backward compatible.
We definitely can't handle 1k users fiddling with their own logics in js (note: lots of "modern" sites kinda prefer working with js even for major parts, so it's going to be a hard battle stating "web2py.js will do all things you require"), but hopefully, if you previously had to rewrite 50 lines of web2py.js to match your requirements, now you can do it in 5 (and if you adopt new web2py.js versions, you need to review/modify/test 5 lines instead of 50), and build things on top of them.

[Paolo Valleri]

Thanks for the whole clarification, from my point of view the current web2py.js is very powerful, and allows us to do several things more easily than before, my concerns are just about the fact that the text replacement in a few cases is too much intrusive. Moreover, my position as a developer is that, I don't want to edit web2py.js because I don't want to delve into the pain of merging it every time is updated in trunk :-P

Given that, I started to develop a very easy kind of "inheritance"

myDisableElement = function (el) {

  if (el.isSpecial()){

    //do something

  } else {

    $.web2py._disableElement(el);

  }

};

$.web2py._disableElement = $.web2py.disableElement;

$.web2py.disableElement = myDisableElement;

The snippet shows a very easy method overriding, the original disableElement will be executed only if the element is not "special".

I wondering if there's a better and more elegant way to do the same thing.

Paolo

[Niphlod]

your position as a developer should instead be "I'm the only one that can take the burden of merging every time that trunk is updated if the feature is marked as experimental and nowhere documented" :-P
I'm glad though that even if it's not documented the code is understandable.
BTW, let's be honest and clear. If you do lots of js logic in your pages, the time that it'll take to eventually refactor something to adapt to an eventually new web2py.js function is close to zero.
If you're expecting a stable api for all the internals that doesn't change a single bit in 6 months, you won't get it: start cooking your own and you can then file the time spent under the reason "modernization and refactoring" instead of "adapting to new web2py.js". I'm betting on the fact that you will definitely save time blaming me on "adapting", but hey, everyone's picks its own poison ^__^

However, I pushed earlier a little bit of modification (including a comment) that will make things easier (regarding text replacement, retaining the old habit). I really really like this --> http://lab.hakim.se/ladda/ , but I can see that web2py has become more and more concerned about including some external tools in the toolbelt to maintain and cherish.

BTW, I don't think that overriding will anyway become any easier than the code you posted. Evaluating all things at run-time attaching to live events lets you do precisely those kind of things, and I've yet to see other (js) frameworks dealing with overriding  at all levels in a more elegant way. Sure, for the particular case web2py.js could check for a 'thisisspecial' data-attribute or class on the element, but it will just work for this problem and not for your following feature request.

[paolo....@gmail.com]

@niphlod, I've noticed that in web2py.js we bind/unbind the event click to objects having the class 'w2pDisabled'. Currently to style an element as disabled we use the css class 'disabled'. By doing that, the element is styled as disabled but you can still click on it making submit etc. This sounds odd.

Is that the wanted behavior?

If not, I will make an update in order to inhibit a click on objects styled as 'disabled'

 Paolo

2013/9/11 Niphlod <nip...@gmail.com>

[Niphlod]

uhm. I don't see any w2pDisabled in the code. There's w2pDisable but it's not a class. it's an event namespace.... 
I'm pretty sure that if you click on a submit button that takes i.e. 5 seconds to complete, it's styled as disabled, its text becomes "working..." and any click on it doesn't fire anything....maybe the only thing that is missing is styling the cursor on hover, but that hardly qualifies as "odd behaviour".

Am I missing something ? It's been a rough week and I'm pretty tired. I'm really sorry if I missed something....in that case please post more details

[Paolo Valleri]

I got it, thank for the explanation!