get form-field name from Field object
I'm in the process of creating a FileBrowseField that inherits from the CharField, but implements similar accessors to the File/ImageField. e.g. get_%s_url Additionally, in the admin, I want it to pop-up a filebrowser to allow me to select the file I want. I'm currently using a modified version of the filebrowser at http://www.vonautomatisch.at/django/filebrowser/ and it's working ok. The problem I'm having now, is that I can't find the name of the form-field that's generated in the admin, so I can set the id of my popup-link be "locate_name.of.the.field". Basically, I've added a string to the help_text of my inherited Field that show's an icon, which pops up the fileBrowser when clicked. To do the popup, I'm calling the javascript function showRelatedObjectLookupPopup from the django admin js folder. What I want to know is, how can I know the name of the that will be created in the form when this Field is used in a manipulator. Man I hope that makes sense. /Marc DM PS. I need this field because I don't want to depend on http for uploading. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: get form-field name from Field object
On Wed, 2006-09-06 at 17:36 -0500, Marc D.M. wrote: > I'm in the process of creating a FileBrowseField that inherits from the > CharField, but implements similar accessors to the File/ImageField. e.g. > get_%s_url > > Additionally, in the admin, I want it to pop-up a filebrowser to allow > me to select the file I want. > > I'm currently using a modified version of the filebrowser at > http://www.vonautomatisch.at/django/filebrowser/ and it's working ok. > > The problem I'm having now, is that I can't find the name of the > form-field that's generated in the admin, so I can set the id of my > popup-link be "locate_name.of.the.field". > > Basically, I've added a string to the help_text of my inherited Field > that show's an icon, which pops up the fileBrowser when clicked. To do > the popup, I'm calling the javascript function > showRelatedObjectLookupPopup from the django admin js folder. > > What I want to know is, how can I know the name of the > that will be created in the form when this Field is used in a > manipulator. > > Man I hope that makes sense. > > /Marc DM > > PS. I need this field because I don't want to depend on http for > uploading. > I'm not sure how cool it is to talk to yourself in public, but I think I've solved my own problem. I havne't found the answer to my question, but I've found out how to add those extra elements to the right of the field. And I feel silly. Use Javascript . duh!! /Marc DM --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: App portability
On Thu, 2006-09-07 at 03:41 +, SmileyChris wrote:
> When moving an app to a different project, I had to go through and fix
> all the references to my project name in code. Is there a better way to
> import my code? Currently I import like:
>
> from projectname.appname.models import Model
>
> It seems like this inhibits portability of apps somewhat. Perhaps there
> could be some sort of "from django.conf import settings" for apps?
>
Well, as far as I know, python's import is relative. So if you're in the
module /home/gray/white.py and you say
import blue
it will first try to find blue.py in /home/gray, so design your imports
carefully.
Second, there's a hack I think I saw on the documentation site (in the
comments), I use it in my urlconf, it goes like :
_package = '.'.join(__name__.split('.')[:-1])
urlpatterns = patterns(_package+'.views',
..
which just assumes that it's loading views from the same directory as
the urls.py file. This is because, a string is needed for urlpatters, a
string to the full python path. Here we determine it at runtime.
Hope this helps.
/Marc DM
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Small change to utils.functional.curry
On Wed, 2006-09-06 at 22:49 -0700, Michael Spencer wrote: > If you're really hunting for speed, there is a significant boost available in > the common special case of a python function curried with one positional > argument. In this case, you can [ab]use the method binding machinery, e.g.: > > def curry3(_curried_fct, *args, **kwargs): > if len(args) == 1: > # Special case where we try to abuse the descriptor > try: > return _curried_fct.__get__(args[0]) > except AttributeError: > # built-ins fail - handle them in the normal way > pass > > def _curried(*moreargs, **morekwargs): > return _curried_fct (*(args+moreargs), **dict(kwargs, ** morekwargs)) > > return _curried > > > This is about twice as fast as curry2 for the case of a python function > curried > with one argument. It also offers better introspection than either curry1 or > curry2, since the original signature is preserved. It's a bigger change than > the curry2 though, since it changes the type of the curry from function to > bound > method. > I like this idea, but I'm curious about that last sentence. Is this necessarily a bad thing? Or maybe I should ask, why does it matter, function vs bound method. Aren't they both callable? Or am I missing something? /Marc DM --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Small change to utils.functional.curry
On Thu, 2006-09-07 at 13:28 -0500, Adrian Holovaty wrote: > On 9/7/06, Michael Spencer <[EMAIL PROTECTED]> wrote: > > Martin's version is indeed faster, but has a 'gotcha' in that it precludes > > passing a keyword arguments named 'fct' to a curried function... > > [...] > > Better to rename fct to something less likely to clash, such as _curried_fct > > Good call, Michael. I've renamed the parameter to '_curried_func' in > changeset 3735. > > > If you're really hunting for speed, there is a significant boost available > > in > > the common special case of a python function curried with one positional > > argument. In this case, you can [ab]use the method binding machinery, e.g.: > > [...] > > This is about twice as fast as curry2 for the case of a python function > > curried > > with one argument. It also offers better introspection than either curry1 or > > curry2, since the original signature is preserved. It's a bigger change > > than > > the curry2 though, since it changes the type of the curry from function to > > bound > > method. > > I was with you until "it changes the type of the curry from function > to bound method." How does it do that? > > Adrian I think what's going on is that in the try : except clause, the return value is the actual bound method, retrieved using the __get__ magic-method. And it doesn't work very well that way either. I've tried Michael's method and the whole house comes tumbling down. See traceback below when trying to load a flatpage. 3735 works pretty well. /Marc DM traceback : Mod_python error: "PythonHandler django.core.handlers.modpython" Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch result = object(req) File "/usr/lib/python2.4/site-packages/django/core/handlers/modpython.py", line 163, in handler return ModPythonHandler()(req) File "/usr/lib/python2.4/site-packages/django/core/handlers/modpython.py", line 140, in __call__ response = middleware_method(request, response) File "/usr/lib/python2.4/site-packages/django/contrib/flatpages/middleware.py", line 10, in process_response return flatpage(request, request.path) File "/usr/lib/python2.4/site-packages/django/contrib/flatpages/views.py", line 23, in flatpage f = get_object_or_404(FlatPage, url__exact=url, sites__id__exact=settings.SITE_ID) File "/usr/lib/python2.4/site-packages/django/shortcuts/__init__.py", line 15, in get_object_or_404 return klass._default_manager.get(*args, **kwargs) File "/usr/lib/python2.4/site-packages/django/db/models/manager.py", line 67, in get return self.get_query_set().get(*args, **kwargs) File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 211, in get obj_list = list(clone) File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 103, in __iter__ return iter(self._get_data()) File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 430, in _get_data self._result_cache = list(self.iterator()) File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 171, in iterator select, sql, params = self._get_sql_clause() File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 444, in _get_sql_clause joins2, where2, params2 = self._filters.get_sql(opts) File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 574, in get_sql joins2, where2, params2 = val.get_sql(opts) File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 622, in get_sql return parse_lookup(self.kwargs.items(), opts) File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 734, in parse_lookup joins2, where2, params2 = lookup_inner(path, lookup_type, value, opts, opts.db_table, None) File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line 785, in lookup_inner intermediate_table = field.m2m_db_table() TypeError: _get_m2m_db_table() takes exactly 2 arguments (1 given) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: CharFields and children defaulting to emtpy string
On Thu, 2006-09-14 at 02:09 +, Gary Wilson wrote: > Out of curiosity, any one know for what reason using empty strings for > CharFields is the Django convention? Technically, isn't an empty > string still data? Isn't it a bit confusing that some fields get > default values and others do not? Explicit better than implicit? > Well, storing NULL vs Empty-string should consume just about the same amount of data or the difference should be insignificant. However, I think it empty-string was used due to the variations in how databases handle NULL values in strings and how to handle the strings ['NULL','Null','nul'] not sure if I read that somewhere or came up with it on my own though. :) /Marc DM --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
On Tue, 2006-09-12 at 14:35 -0500, Adrian Holovaty wrote:
> The template would look like this:
>
>
> {% if form.sendername.errors
> %}{{ form.sendername.errors.as_ul }}{% endif %}
> Your name: {{ form.sendername.as_text }}
>
> {% if form.senderemail.errors %}{{ form.senderemail.errors_as_ul
> }}{% endif %}
> Your e-mail: {{ form.senderemail.as_text }}
>
> {% if form.subject.errors %}{{ form.subject.errors.as_ul }}{%
> endif %}
> Subject: {{ form.subject.as_text }}
>
> {% if form.message.errors %}{{ form.message.errors.as_ul }}{%
> endif %}
> Message: {{ form.message.as_textarea }}
>
>
>
Alas, it seems I'm the only one wanting to have the form framework
handle buttons as well.
Now I'm not asking for the Form to automatically have submit buttons,
what I'm asking for is to be able to have a ButtonField or
GroupOfButtonsField .
Example:
I just finished working on a multi-page form that uses three
with values value="<
prev" value="next >" and value="cancel"
The value of request.POST["action"] always has the correct
value. [1] That is, the value for the button that was clicked.
So I'm able to use it in processing.
This value though, is the only one not handled by the
Manipulator.
Now I see in this new Form thing, you're ignoring buttons completely.
Am I wrong to assume that the value of the button clicked can be
important? Or is it not important enough?
/Marc DM
[1] I tested it in Firefox 1.5 and Epiphany on Gnome 2.14 and IE6 and
IE4.01 on Win2k. In ie4, I had to remove the styling from the buttons so
I could click them but they submit the correct value. Contrary to what I
heard in #django
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
