Re: Announcing new django project

[h3]

> Looks pretty cool, and maybe this is just my naivety at work, but how 
does form validation work with this?

It's actually pretty simple. A form is generated on the fly for each 
editlive field using modelform_factory:
https://github.com/h3/django-editlive/blob/master/editlive/adaptors/base.py#L45

Then when saving, I check the form for field errors:
https://github.com/h3/django-editlive/blob/master/editlive/adaptors/base.py#L195

It might be useful eventually to add support for custom forms, I don't 
think it would be very hard to implement.

Regards,

--

  Maxime Haineault
  Consultant Web / Associé

∞ Motion Média  
   http://motion-m.ca
   m...@motion-m.ca
   (450) 747-0862

On Friday, February 1, 2013 8:12:32 AM UTC-5, JoeLinux wrote:
>
> Looks pretty cool, and maybe this is just my naivety at work, but how does 
> form validation work with this?
>
> --
> Joey "JoeLinux" Espinosa*
> *
> <http://therealjoelinux.blogspot.com> 
> <http://twitter.com/therealjoelinux><http://about.me/joelinux>
>  
>
> On Fri, Feb 1, 2013 at 12:25 AM, h3 <hain...@gmail.com >wrote:
>
>> Hi everybody,
>>
>> I would like to introduce you my latest project: django-editlive
>>
>> It can make any database object editable in template with a simple 
>> template tag.
>>
>> More informations, including demos and docs here: 
>> http://editlive.motion-m.ca
>>
>> Feedback would be appreciated.
>>
>> --
>>
>>   Maxime Haineault
>>   Consultant Web / Associé
>>
>> ∞ Motion Média  
>>http://motion-m.ca
>>m...@motion-m.ca 
>>(450) 747-0862
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Announcing new django project

[h3]

Hi everybody,

I would like to introduce you my latest project: django-editlive

It can make any database object editable in template with a simple template 
tag.

More informations, including demos and docs here: 
http://editlive.motion-m.ca

Feedback would be appreciated.

--

  Maxime Haineault
  Consultant Web / Associé

∞ Motion Média  
   http://motion-m.ca
   m...@motion-m.ca
   (450) 747-0862

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Django 1.4: No wrapping of exceptions in TEMPLATE_DEBUG mode

[h3]

>From the doc:

> In previous versions of Django, whenever the TEMPLATE_DEBUG setting was True, 
> any exception raised during template rendering (even exceptions unrelated to 
> template syntax) were wrapped in TemplateSyntaxError and re-raised. This was 
> done in order to provide detailed template source location information in the 
> debug 500 page.
>
> In Django 1.4, exceptions are no longer wrapped. Instead, the original 
> exception is annotated with the source information. This means that catching 
> exceptions from template rendering is now consistent regardless of the value 
> of TEMPLATE_DEBUG, and there's no need to catch and unwrap 
> TemplateSyntaxError in order to catch other errors.

Pretty cool .. I guess. But now how can I see raised exceptions ?

If I include a template or call a template tags which raise an
exception, nothing happen.

I appreciate the added robustness.. but without clear documentation on
how to show those exception, debugging is a bit painful.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: manage.py --settings breaks IPython

[h3]

Doesn't work..

> Error: Usage is runserver [optional port number, or ipaddr:port]

And if I do the opposite:

$: python manage.py runserver --settings=settings_dev --

Same problem comes back.

On Oct 19, 12:52 pm, James Pyrich <ja...@pyrich.com> wrote:
> It might be attempting to interpret --settings as a Python option.  Try
> the following:
>
> $: python manage.py runserver -- --settings=settings_dev
>
> Any Python-specific settings go before the double-dash, etc., etc.
>
> On 10/19/2011 12:11 PM, h3 wrote:
>
>
>
>
>
>
>
> > I like to use IPython for debugging when developping, but it breaks if
> > I use the --settings argument..
>
> > So if I do this:
>
> > $: python manage.py runserver --settings=settings_dev
>
> > The server will run, but when IPShellEmbed is invoked I get this
> > error:
>
> >> Error in Arguments: "Illegal option '--settings=settings_dev'"
> > When I do the same without the --settings=settings_dev everything
> > works as expected..
>
> > Any idea how I could workaround this ?
>
> > Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

manage.py --settings breaks IPython

[h3]

I like to use IPython for debugging when developping, but it breaks if
I use the --settings argument..

So if I do this:

$: python manage.py runserver --settings=settings_dev

The server will run, but when IPShellEmbed is invoked I get this
error:

> Error in Arguments: "Illegal option '--settings=settings_dev'"

When I do the same without the --settings=settings_dev everything
works as expected..

Any idea how I could workaround this ?

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: can django be used in destop application?

[h3]

Django is modular enough that most of its parts could probably be
replaced with desktop oriented
modules, like rendering QT templates instead of HTML templates.. which
is great.

If not you can probably use a embed browser engine (like webkit) and
run your app like a website
locally and get somewhat the look and feel of a desktop application.

That said, your real problem will arise when your application will
need to do things that doesn't adhere to
the REST api. Then you'll need to find a way to save your application
state and that's pretty much
when shit will hit the fan IMHO.

If the desktop application(s) you want to build are all easily
translatable for the web (using a REST api that is),
I think it's theoretically possible. But try to do anything out of
this scope and you will bitten at every corners.

In other words, not really worth the troubles.

regards,

Max


On Aug 23, 1:36 pm, "Cal Leeming [Simplicity Media Ltd]"
 wrote:
> Curious concept, using Django for a desktop application.
>
> Can't think of any reason why you couldn't at least try it :)
>
> Cal
>
> On Tue, Aug 23, 2011 at 3:49 PM, Andy McKay  wrote:
>
> > On 2011-08-23, at 4:17 AM, smith jack wrote:
>
> > > i mean not use django for web site development, but for desktop
> > application,
> > > it seems its orm can be used in destop application， isn't it?
>
> > Yes.
> > --
> >  Andy McKay
> >  a...@clearwind.ca
> >  twitter: @andymckay
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Annoucing python-dad

[h3]

"Python-dad which stands for Django Automated Deployment is a
lightweight Python package which harness the power of virtualenv, pip
and fabric to fully automate the development setup and deployment of
django projects. "

Blog post: http://haineault.com/blog/163/
Project page: http://code.google.com/p/python-dad/

Looking for contributors :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Detecting if i18n/10n are installed from a template

[h3]

Just answered my own question .. if request.LANGUAGE_CODE isn't in
context .. it's not.

Meh.

On Jul 25, 11:00 pm, h3 <hainea...@gmail.com> wrote:
> Is there a mechanisme to detect if i18n/10n are installed from the
> template code ?
>
> I don't see anything about it in the official doc..

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Detecting if i18n/10n are installed from a template

[h3]

Is there a mechanisme to detect if i18n/10n are installed from the
template code ?

I don't see anything about it in the official doc..

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django inline formset gotcha

[h3]

Well .. nevermind.

http://haineault.com/blog/142/


On Nov 6, 10:50 pm, h3 <hainea...@gmail.com> wrote:
> I've been banging my head on this problem for many hours and nobody
> came up with a
> working solution ..
>
> I've tried so many things to work around this problem that I've
> decided to write a blog
> listing them to save you all some time:
>
> http://haineault.com/blog/141/
>
> TL;DR: inline formset + post_save signal = cannot access inlines'
> updated data.
>
> Think of an invoice system were the inlines are the invoice's lines
> which you use to
> calculate the invoice's total.
>
> You just can't have that total upon save nor with post_save signal
> under *any* circumstances.
> Unless you hit the save button twice, then the second time the right
> total will show up. Of
> course this is problematic on many levels, but in my case I need to
> send an email with the
> actual data after the save.
>
> Please someone tell me I'm retarded and that there is a simple obvious
> solution hidden in plain
> sigh that escaped me.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Django inline formset gotcha

[h3]

I've been banging my head on this problem for many hours and nobody
came up with a
working solution ..

I've tried so many things to work around this problem that I've
decided to write a blog
listing them to save you all some time:

http://haineault.com/blog/141/

TL;DR: inline formset + post_save signal = cannot access inlines'
updated data.

Think of an invoice system were the inlines are the invoice's lines
which you use to
calculate the invoice's total.

You just can't have that total upon save nor with post_save signal
under *any* circumstances.
Unless you hit the save button twice, then the second time the right
total will show up. Of
course this is problematic on many levels, but in my case I need to
send an email with the
actual data after the save.

Please someone tell me I'm retarded and that there is a simple obvious
solution hidden in plain
sigh that escaped me.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Question about search and filters

[h3]

If you want full context of this questions, you can read this blog
post and the first two comments: http://haineault.com/blog/134/

That said, here's the TL;DR version;

I'm trying to rethink the interface design of the search/filter/date
hierarchy in the django admin (with Grappelli, not vanilla admin..).

And someone pointed out it would be nice to be able to change the
order of filters ..

Theoretically I know it is doable and it could be reflected in the
order of the GET parameters sent to the server .. but my question is,
does the ORM care about the order the parameters are sent ?

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.