On Fri, 2006-07-28 at 18:19 +0200, Steven Armstrong wrote:
> On 07/28/06 02:02, Malcolm Tredinnick wrote:
> > On Thu, 2006-07-27 at 16:44 -0700, Malcolm Tredinnick wrote:
> >> On Thu, 2006-07-27 at 17:30 -0600, Jay Klehr wrote:
> >> > Nagy Károly wrote:
> >> > > And Jay, (afaik) CSS controls visual size of field, not the number of
> >> > > characters you can type in (VARCHAR(30) field in 600px input widget
> >> > > means 2/3 of a box is empty)
> >> > >
> >> > > Charlie.
> >> > >
> >> > Exactly, the visual size, which is the same as the "size" html
> >> > attribute, which also has no control of how many characters can be
> >> > entered into the field. The "maxlength" html attribute does control the
> >> > number of characters allowed in the field, which CSS doesn't do, as
> >> > stated poorly in my previous email. ;)
> >>
> >> Quite seriously, one way to make it easier to evaluate this would be for
> >> somebody to finish up the remaining parts of ticket #1665. I'm not
> >> saying 100% it will be accepted, since it leaks a bit across the line
> >> between representation and presentation, but there may be no other good
> >> way to do it, so it's not being rejected out of hand.
> >
> > Sorry, that came across a bit more negatively than I intended: it almost
> > certainly will be accepted (see the threads linked from the bug). So
> > it's not a roll of the dice -- the solution isn't ideal, but barring a
> > better solution, it is a reasonable idea.
> >
>
> I've extended some of django's built in model and form fields to accept
> an additional kwarg named 'html_attributes'.
>
> It works like this:
>
> class Whatever(models.Model):
> ...
> title = models.CharField(maxlength=128,
> html_attributes={
> 'size': 15,
> 'class': 'myCssClass'
> }
> )
> content = models.TextField(
> html_attributes={
> 'dojoType': 'Editor',
> 'items': 'formatBlock;textGroup;|;justifyGroup'
> }
> )
> ...
This is the sort of thing that maybe starts crossing the line between
representation and presentation a bit too much. You are putting a lot of
presentation information into the data model description and they
should, as much as possible be separate. That is why I (and others) are
a bit conservative even about putting the textfield length into the
model: it's a leaky abstraction issue and a slippery slope, all in one.
Once we take one thing, where does it stop? Ultimately, we are going to
have to draw the line and it will seem arbitrary to people who aren't
thinking of this as "every single presentation item in a model is there
as a slight wart on the utopian design."
I would rather see people put some effort into working out how you can
write a view-layer infrastructure that annotates a model somehow with
the "default visual description" you want. There is nothing against you
making those annotations in the same file as the model descriptions
themselves, but it will help keep the data description and the
presentation information separate. Long lines of code are harder to
maintain, which is why we endeavour to keep things somewhat apart and
compartmentalised where possible. This "annotation" could be an inner
class or something like that -- I don't know; I haven't put a lot of
thought into it. I just feel that something like that would be a better
expenditure of effort than hacking on the existing model stuff to tie it
to a particular visual representation.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---
