On 07/28/06 19:46, Malcolm Tredinnick wrote:
> 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 agree whole heartedly.
> 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.
>
My first idea was, just as you propose, to create another inner class or
something which holds this kind of information. But I needed a solution
quickly and the hack I did worked without breaking anything else.
Also I only had to get my head around a small part of django's internals
to implement it. Hacking on the metaclass/inner class stuff is a
different kind of beast.
I guess we should discuss what kind of information should/could go into
this new inner class and figure out a good name for it so I or others
can take a shot at it.
While we're at it there are probably a few settings currently passed as
Field arguments which could/should also be moved.
From a quick look at the model_api the following seem to be candidates:
- editable
- radio_admin
- help_text
(the ones below should maybe go in the Admin inner class?)
- edit_inline
- max_num_in_admin
- min_num_in_admin
- num_extra_on_change
- num_in_admin
- raw_id_admin
- filter_interface
Then again it's maybe better to leave the existing stuff where it is as
it would mean a lot of work to refactor it all out.
But then creating an inner class to hold only one 'html_attributes'
property feels a bit weired to. What else have we got that would fit in
there?
Ideas? Requirements? Opinions?
cheers
Steven
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
