Russel,
I examined the svn tree and the patches. It seems that the diffs are for the
widget.py file under 'newforms', but this directory does not exist in the svn
tree. I've tried appending the widget classes from the ticket to:
/usr/lib/python2.5/site-packages/django_src/django/forms/widgets.py
I then end up in an 'import galore', that results in modifying files in the app
and the django source tree in more places then seems healthy. Also ending up
changing referencing, e.g. adding the extra 'widgets.' like this
widget=widgets.DateFormattedTextInput() for instance.
Then the best scenario I got without errors was a form.as_table that dit not
generate a form. And the funny thing is everything does work when testing in
'./manage.py shell'
Besides all that, the actual way that really works, was to simply add a
'datetimewidgets.py' with the classes to my app and import it.
Since I would like to have it in the source tree properly ...
Is the aformentionted widgets.py the right file (couldn't find that in the
ticket) to place the new classes?
Should this sysadmin stay with the simple solution ... :-) and not put it in
the source tree?
Is there (besides the source code ... ;-) any reading in regards to Django how
this is setup?
Thanx a lot!
Regards,
Gerard.
Russell Keith-Magee wrote:
> On Thu, Oct 2, 2008 at 7:00 PM, Gerard Petersen <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> I'm in need of the functionality of ticket #3672. I have de initial code
>> implemented. And there are some patches, but they seem to be diffs on files
>> in the main svn trunk.
>
> Yes - diffs against the source tree are the preferred format for
> suggesting changes to Django.
>
>> The question with the easiest solution for me would be, when is the code
>> from this ticket going to be merged with svn.
>
> Sorry to seem obtuse, but the answer is somewhere between now, and the
> eventual heat death of the universe.
>
> This isn't a question that can be answered with a precise answer like
> "on Tuesday afternoon". The core developers are all volunteers, so
> bugs get fixed when we have time, and there isn't a strict queue or
> order in which they get fixed.
>
> The only way to ensure that a patch is included is to catch a core
> developer's attention and convince him (or her) that the patch needs
> to be applied.
>
>> Otherwise, if I patch the local working copy my next 'svn up' will raise
>> conflicts. Does anybody have some wise words on this?
>
> It sounds like you need to spend some more time playing with version
> control systems. This sort of problem is one of the problems that
> version control systems like SVN are designed to handle - a mainline
> that keeps changing while maintaining local modifications.
>
> If you have a checkout of trunk, and you apply the patch providing
> this functionality, you will have a local version of Django that uses
> the patch. When you next run "svn up", your trunk checkout will be
> updated, and your patched code will come along for the ride. After the
> update, you should have an updated checkout with the patch applied.
>
> The only time you will have a conflict is when a change that is part
> of the SVN update conflicts with the change made by the patch - for
> example, if a separate problem with DateField was fixed. In this case,
> you will need to manually resolve the conflict. However, for most
> day-to-day updates, this won't be an issue - you should be able to
> update without difficulty.
>
> Yours,
> Russ Magee %-)
>
> >
--
urls = { 'fun': 'www.zonderbroodje.nl', 'tech': 'www.gp-net.nl' }
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---
