Thank You very much for answer :)

To the POST hooks :) or URL hooks. IMHO there are many ways to pass
arguments to hook like this. I think this will be good to have
something like "method" argument in hook calling which could be
similar to jquery.ajax argument. Which means when we call hook we
could determine how arguments hook will be send:
POST, GET or JSON or something else. My little suggestion :)

I belive this mechanism will be good enough to customize reviewboard
external integrations :]

About branches. Now I see one problem.
I'am providing some features to ReviewBoard (more fixes for ClearCase
then features but features will be there also) and I post reviews for
it. But there are some features which  have sens only for my company,
and I just keep them in another branch without posting it public.
Which branch I should use? Now I use default one from github. Now I
see there is another branches where some of features which I need
(maybe which I implement by my self) are present :) I don't want
implement features which is available now. No I'am a little bit
confused which branch I should use to have stable ReviewBoard, may
post reviews and write patches and get unpublic features not provide
in ReviewBoard yet? Is there any branch like this? :D

Thank You for Your answers :)

On Apr 6, 5:14 am, Christian Hammond <chip...@chipx86.com> wrote:
> Hi,
>
> We have a few things planned and in development for the level of
> customization you guys want.
>
> 1) We have some things that will be in the 1.6 release (it's actually
> written today, just isn't scheduled for 1.5) for WebHooks, which allow for
> calling external scripts (technically, doing an HTTP POST to a URL) on
> various events. I can't remember exactly if Submitted or Discarded hooks
> into this, but it could be made to if it doesn't.
>
> I'll probably create an early 1.6 branch for development before long which
> will have this. You could make use of this branch if you want to use this
> sooner, though you'd have to maintain your own packages internally.
>
> The way it works is that you have a script hosted on a web server somewhere.
> It could be PHP, Python, whatever. It responds to an HTTP POST and knows how
> to take a certain payload and return certain information. You would then
> reference this URL in the admin UI for different events.
>
> 2) It's quite possible we'll have some level of theme support (perhaps as a
> Summer of Code project) for letting admins configure their own templates by
> basically just overriding parts that they need. That's not happening for
> 1.5, but maybe 1.6.
>
> 3) We're working on extensions support. There are branches for it today, but
> it's nowhere near ready for production use. However, it will allow for more
> advanced customization without modifying Review Board.
>
> As for the suggestions for changing how settings works, I'd actually rather
> do nothing about this right now. I feel that while we'd get a lot of
> flexibility, it would increase our support burden, and there's rarely a case
> where this would need to be used anyway. The customizations you're
> referencing will be there in a much easier way in future releases, and if
> you really need to specify your own TEMPLATE_DIRS, you can define it without
> inheriting and just shove the old values in there. Much easier than a whole
> new import mechanism :)
>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board -http://www.reviewboard.org
> VMware, Inc. -http://www.vmware.com
>
> On Sat, Apr 3, 2010 at 12:11 AM, Jan Koprowski <jan.koprow...@gmail.com>wrote:
>
>
>
> > Hi!
>
> >  I'am start using reviewboard and need some customizations:
> >  1) I need hooks run after Submited or Discarded
> >  2) Add custom footer, change logo, title
>
> >  First thing is a way to customize some layoutes. I know how I can do
> > that now:
> >  * copy templates from reviewboard to my folder
> >  * set in my settings_local TEMPLATE_DIRS to my directory and
> > oryginal directory (for example symlink somewhere inside my instance
> > created by rb-site)
> >  but this option have one limitation. Upgrading my ReviewBoard need
> > to check is modified by me templates doesn't change... hmmm.
>
> >  My idea is made some modifications in settings_local which allow not
> > only overwrite existing settings but modify it.
> >  My first try looks like:
> >  settings_local.py
> >  -----------------------------------------------
> >  import reviewboard.settings
> >  TEMPLATE_DIRS = (
> >      r'/my/custom/dir'
> >  ) + reviewboard.settings.TEMPLATE_DIRS
> >  -----------------------------------------------
> >  but this doesn't have effect. I guess problem in import recursion.
> > settings_local import settings and settings import settings_local.
> > Python make it and modify TEMPLATE_DIRS but Django doesn't catch
> > this.
>
> >  So the second shoot is change some ways.
> >  * settings.py > settings_default.py
> >  * settings_local.py
> >  -----------------------------------------------
> >  from reviewboard.settings_default import *
> >  [...
> >  ...
> >  ...]
> >  some custom modifications
> >  * settings.py
> >  -----------------------------------------------
> >  try:
> >     from settings_local import *
> >  except:
> >     from default import *
>
> >  some neccessery checks and customizations
>
> >  This is the way (i think) good enough which provide some features
> >  1) We have our default values
> >  2) User can change anything in settings_local. Overwriting is only
> > one option. There can be also modification! They can add some custom
> > template directory before templates from reviewboard (and create their
> > own templates) or not :] Second grate benefit is way to add some
> > custom plugins (MIDDLEWARE_CLASSES or APPS) which allow to do many
> > greate things.
>
> >  Unfortunetly I don't know how this looks with merging with Django
> > source tree so :] there is second option (IMHO a little bit worse then
> > first one)
> >  At the end add loop which check settings_local under MYRB_PRE_ and
> > MYRB_POST_ prefixed variables and add/append values to existing once.
> >  for variable filter(lambda s: s.startswith('MYRB_PRE_'),
> > dir(settings_local))
> >      [...]
> >      globals()[varname] = variable + globals()[varname]
> >  for variable filter(lambda s: s.startswith('MYRB_POST_'),
> > dir(settings_local))
> >      [...]
> >      globals()[varname] = globals()[varname] + variable
>
> >  IMHO first option is much more clear and flexible and bettter
> > designed then first one. What do You think? I can prepare review for
> > this concept.
>
> > Greetings from Poland!
> > --
> > Jan Koprowski
>
> > --
> > Want to help the Review Board project? Donate today at
> >http://www.reviewboard.org/donate/
> > Happy user? Let us know athttp://www.reviewboard.org/users/
> > -~----------~----~----~----~------~----~------~--~---
> > To unsubscribe from this group, send email to
> > reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegr 
> > oups.com>
> > For more options, visit this group at
> >http://groups.google.com/group/reviewboard?hl=en

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

To unsubscribe, reply using "remove me" as the subject.

Reply via email to