Form Object Capable of Streamlining AJAXy Things.
Everyone knows. Client-side validation is often just a first line of
defense for UIX purposes. Doing client-side and server-side
validation requires writing/hooking up the same validator twice. The
code in question is hardly unique. Neither is the signature nor flow
control of the client-side form loaders, validators, or processors.
RY.
An AJAX form that might get loaded dynamically then has to validate
itself, ask the server if all went well, and maybe reload errors and
submit again, rinsing and repeating before re-hiding the div/iframe.
The load has to either accept a second parameter or hit another URL.
Flow control gets into the view or bloats the URL's. Either way, the
server needs to know the difference between the different requests.
In place of a hodge-podge of user code that can so frequently be
boiled down to:
1. Load form (if form was in an iframe, reveal it.)
2. Validate user input
3. Submit to server and ask for errors
4. If errors, ask for the errors and display them
5. All clear. Present feedback to user
What I would propose is an extended form object on the server that can
do the following:
1. Prior to cleaning, determine which type of request is being asked
for
2. Provide context to the template to say whether to reload with the
javascript or just the AJAX relevant fragment. Corresponding template
tags like {% subTemplate %} to avoid trivial template nesting.
3. Ability to pass other data parameters back to the AJAX call in
addition to the html string that needs display on the client.
4. Outputs HTML that is logically and uniquely identified so that
AJAX processing code can predictably and without-wrist-breaking update
client-side error messages (usually overwriting the server-side
feedback).
5. Guts. No system like this is useful if it doesn't have obscure
options for writing the form's nth element inside a specific canvas
tag etc.
I have the following gripes against my own solutions:
0. HAND-WRITING FORM HTML OR USING SUB-FORM TEMPLATE TAGS SO MY AJAX
CODE KNOWS WHAT TO VALIDATE AND WHERE TO PUT SERVER-SIDE FEEDBACK. =)
1. Occasionally my js code becomes template-aware, telling the server
exactly what to load. A template naming scheme helps, but in the end
my code is broken into too many pieces.
2. I also do event management where the ultimate processing of a form
calls a method on the main page (the event callback) which might
cause other AJAX elements to update (user login for instance). Good
naming schemes help, but once again I'm putting code in seven places
to do one (potentially many, but usually less than seven) things.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Anonymous session carries over to authenticated session
Posted original on the Django Users group because I thought I was missing something: http://groups.google.com/group/django-users/browse_thread/thread/a612987d2c3487e4 Per what Tom mentions on the Django Users thread: - an authenticated user logging in under a different account keeps the session key, but session data is flushed - a non-authenticated user keeps the session data but gets a new session key This behavior is confusing especially the latter since data was persisted pre-auth to post-auth even though the session key changed. There is certainly utility for persisting post-auth (e.g. e-commerce), but this is not documented anywhere. How would everyone feel about making this a setting, e.g. SESSION_FLUSH_AT_LOGIN? If false, it would behave as it does now otherwise it would flush the non-auth session. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Anonymous session carries over to authenticated session
Here is the relevant code: https://github.com/django/django/blob/master/django/contrib/auth/__init__.py#L63-70 On Nov 15, 1:44 pm, Byron Ruth wrote: > Posted original on the Django Users group because I thought I was > missing > something:http://groups.google.com/group/django-users/browse_thread/thread/a612... > > Per what Tom mentions on the Django Users thread: > > - an authenticated user logging in under a different account keeps the > session key, but session data is flushed > - a non-authenticated user keeps the session data but gets a new > session key > > This behavior is confusing especially the latter since data was > persisted pre-auth to post-auth even though the session key changed. > There is certainly utility for persisting post-auth (e.g. e-commerce), > but this is not documented anywhere. > > How would everyone feel about making this a setting, e.g. > SESSION_FLUSH_AT_LOGIN? If false, it would behave as it does now > otherwise it would flush the non-auth session. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Anonymous session carries over to authenticated session
On Nov 15, 10:44 am, Byron Ruth wrote: > > How would everyone feel about making this a setting, e.g. > SESSION_FLUSH_AT_LOGIN? If false, it would behave as it does now > otherwise it would flush the non-auth session. I do think the current behavior is worth a note in the docs - like you say - there are reasons to not flush it. but this doesn't seem to merit a setting in the face of the ever growing problem of settings bloat. If https://code.djangoproject.com/ticket/17209 comes to pass, this could be something on a login class, but otherwise I think you are better off just doing a custom login view if you want to flush the session. -Preston -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Anonymous session carries over to authenticated session
Indeed, all of the settings are slowly becoming unwieldy. I will write my own `login()` function in the meantime, but the docs should definitely be update to note this behavior. On Nov 15, 2:27 pm, ptone wrote: > On Nov 15, 10:44 am, Byron Ruth wrote: > > > > > How would everyone feel about making this a setting, e.g. > > SESSION_FLUSH_AT_LOGIN? If false, it would behave as it does now > > otherwise it would flush the non-auth session. > > I do think the current behavior is worth a note in the docs - like you > say - there are reasons to not flush it. > > but this doesn't seem to merit a setting in the face of the ever > growing problem of settings bloat. > > Ifhttps://code.djangoproject.com/ticket/17209comes to pass, this > could be something on a login class, but otherwise I think you are > better off just doing a custom login view if you want to flush the > session. > > -Preston -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Anonymous session carries over to authenticated session
Ticket opened for documentation: https://code.djangoproject.com/ticket/17236 On Nov 15, 3:35 pm, Byron Ruth wrote: > Indeed, all of the settings are slowly becoming unwieldy. I will write > my own `login()` function in the meantime, but the docs should > definitely be update to note this behavior. > > On Nov 15, 2:27 pm, ptone wrote: > > > > > > > > > On Nov 15, 10:44 am, Byron Ruth wrote: > > > > How would everyone feel about making this a setting, e.g. > > > SESSION_FLUSH_AT_LOGIN? If false, it would behave as it does now > > > otherwise it would flush the non-auth session. > > > I do think the current behavior is worth a note in the docs - like you > > say - there are reasons to not flush it. > > > but this doesn't seem to merit a setting in the face of the ever > > growing problem of settings bloat. > > > Ifhttps://code.djangoproject.com/ticket/17209comesto pass, this > > could be something on a login class, but otherwise I think you are > > better off just doing a custom login view if you want to flush the > > session. > > > -Preston -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
