dynamic search forms
Hello, this is my first post to the list. Great to work with such a well- designed framework! My question - is there an 'official' way to build dynamic search forms where users can add/remove search criteria? And if not: How would I best deal with search param names that are not initially known server side? I could come up with some handcrafted solution, but I'm looking for best practices here to avoid unnecessary trouble. best regards, Christoph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
A Semantic Web CMS
Am 19.04.2007 um 17:56 Uhr schrieb Nicola Larosa: > It looks like they are working mostly on the client side, but > something > tells me that the need for a server side will arise, sooner or > later. It > would be great exploring that side with Django. Interesting discussion. I'm just about to implement a slightly 'semantish' serverside backend in django - it's the fourth incarnation acutally: the first was done with python and the zope DB (it just produced XML files that were eaten by a Flash interface), the second was done with mod_python, Apache and MySQL, number three Zope and postgreSQL. I've been playing around with django for some weeks now, and I like the approach a lot. I was surprised how quickly I could reimplement the functionality of my architecture (it's called 'paragon') in django, for you interest here's the models. My aim is to combine the strictness of semantics with the flexibility of a kind of 'digital scrapbook' (in Germany, we speak of a 'Zettelkasten' or 'sheetbox'). As you can see, I don't care about restrictions very much - classes can be abstract or concrete, there's no concept of cardinality etc. Inheritance is also only 'nominal' yet: As soon as an object has the relation 'is_instance_of' or 'is_subclass_of', the business logic has to know how to deal with that. The main advantage is that I can model almost everything with this approach: persons, topics, books, exhibitions, conferences, scientific paradigms, person's affilitations etc. The project began in the arts field as an 'open source webbased ontology' for the arts and related fields like architecture, psychology, physics, cognitive scienence. If you'd like to look at the current implementation: http:// www.christoph-pingel.de/paragon/objectpage/George_Lakoff Comments, proposals, criticism are welcome. I'm quite new to django, so perhaps I'm missing some things to make the design even more sober and easy to maintain. best regards, Christoph Here's the models if you'd like to play with it: from django.db import models class pg_object(models.Model): """ Objects and Classes of Objects """ object_name = models.CharField(maxlength=300) def __str__(self): return self.object_name class Admin: pass class pg_atm(models.Model): """ A thesaurus of possible attribute meanings. A theasaurus means less ambiguity and better possibilities to map e.g. BibTex entries in a controlled manner """ # atm_bedeutung = models.CharField(maxlength=200) -- it's probably better to use a more generic approach vs. i18n. atm_meaning = models.CharField(maxlength=200) def __str__(self): return self.atm_bedeutung class Admin: pass class pg_rlt(models.Model): """ Possible relations between objects. I'm not sure if it's possible (nor how) to implement a ForeignKey into the same table """ rlt_relation = models.CharField(maxlength=200) rlt_backrelation_id = models.IntegerField() rlt_times_used = models.IntegerField() def __str__(self): return self.rlt_relation class Admin: pass class pg_atp(models.Model): """ Here we store the actual poperties/slots, whatever you call it. Each key/value pair exists only once. Objects register properties via a link table (pg_oal below) """ atp_bedeutung = models.ForeignKey(pg_atm) atp_value = models.TextField() def __str__(self): return "%s %s" % (self.atp_bedeutung, self.atp_value) class Admin: pass class pg_oal(models.Model): """ The link table for objects to register properties 'oal' stands for object attribute link """ oal_object = models.ForeignKey(pg_object, edit_inline=models.TABULAR, num_in_admin=3) oal_attribute = models.ForeignKey(pg_atp, core=True) def __str__(self): return "%s %s" % (self.oal_object, self.oal_attribute) class Admin: pass class pg_ool(models.Model): """ The link table for objects to relate to other objects (or classes). 'ool' stands for object object link """ ool_source = models.ForeignKey(pg_object, related_name="Quelle der Relation") ool_relation = models.ForeignKey(pg_rlt) ool_target = models.ForeignKey(pg_object, related_name="Ziel der Relation") def __str__(self): return "%s %s %s" % (self.ool_source, self.ool_relation, self.ool_target) class Admin:
Re: duplicate key value violates unique constraint "django_admin_log_pkey"
Thanks, this helped me too 2 years later.. :-)
On Thursday, October 14, 2010 6:23:37 PM UTC+2, reduxionist wrote:
>
> On 14 ต.ค. 2010, at 22:24, glob...@iamsandiego.com wrote:
>
> > Hi Folks,
> >
> > After updating a postgres db for my django app Iam getting this error
> > when I try and save new data to the db:
> >
> > Request Method: POST
> > Request URL: http://10.50.253.200/admin/survey/gps/add/
> > Django Version: 1.2 beta 1
> > Exception Type: IntegrityError
> > Exception Value:
> >
> > duplicate key value violates unique constraint "django_admin_log_pkey"
> >
> > Is there any way to correct this?
>
> Sounds to me like your DB update has reset the sequence
> "django_admin_log_id_seq" used by postgres to get the next value for the
> "auto-increment"-type id field used by django_admin_log.
>
> I would manually reset the sequence via the following:
>
> First get the id value of the last admin entry:
>
> select id from "django_admin_log" order by id desc limit 1;
>
> Then set the next value of the ID sequence to that + 1 via:
>
> select setval('django_admin_log_id_seq', LASTID+1);
>
> (replacing LASTID+1 with the result of the first query +1 obviously...)
>
> The other option would be to "delete * from 'django_admin_log';" so that
> the old ids are gone and you can start over from 1 - but then you lose your
> whole admin history which seems sub-optimal.
>
> Haven't run into the problem myself though, so this is just a guess, and
> from a Django newbie so...
>
> Hope it helps!
> Jonathan
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/29-tT_F6SlMJ.
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.
WSGI eating search args?
My app runs with mod_wsgi behind Apache.
A local configuration of the app runs without problems, but behind
Apache every call involving GET args results in a HTTP 500 error.
The url config is
(r'^sem/search/$', 'paragon.sem.views.search'),
and in my view, I get the search param with
query = request.GET.get('q', '')
Strange thing is, if I call the view without query args, the page
renders beautifully, but with query args, I get HTTP 500.
The problem seems to be systematic, none of the urls that use GET args
seems to work. Any ideas what the problem could be?
django 1.2.5, apache2.
TIA,
best regards,
Christoph
--
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: WSGI eating search args?
Thanks, I tracked it down. Nothing to do with WSGI, it's just that SQLite doesn't support REGEXP on the target platform. best regards, Christoph On Feb 24, 12:22 pm, Tom Evans wrote: > > You get a 500 if your view raises an exception. Since you aren't > showing the exception traceback, any advice would be speculation. > > Cheers > > Tom -- 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.
