HtmlPurifier... gone... gone

[Tim Almdal]

I was just thinking... 2 things actually:

• Now that HtmlPurifier is in -contrib what type of upgrade code should be there to reflect this move?

What I was going to do is put up a site-status if HtmlPurifier was not installed (basically saying: "by default we encode html on output.  If you would like to render the html properly please  click <link to htmlpurifier codex page> to find more information.  Otherwise click here<link to gallery controller to clear the message> to accept this default.")

• Is there any value in combining message helper and site-status helper.  The only real difference is that site-status public methods require a permanent key. We could combine the api by adding a permanent-key parameter with a default of null.  If its null we just store it in the session, otherwise store it in the database. thoughts?

Tim



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Tim Almdal wrote:

> I was just thinking... 2 things actually:
>
>     * Now that HtmlPurifier is in -contrib what type of upgrade code
>       should be there to reflect this move?
>
> What I was going to do is put up a site-status if HtmlPurifier was not
> installed (basically saying: "by default we encode html on output.  If
> you would like to render the html properly please  click <link to
> htmlpurifier codex page> to find more information.  Otherwise click
> here<link to gallery controller to clear the message> to accept this
> default.")

I don't think we don't need any upgrader code since this is just beta
code.  We can deal with the fallout in the forums.  I doubt too many
people are using HTML in their G3 installs anyway.  (maybe I'm really
wrong?)

>     * Is there any value in combining message helper and site-status
>       helper.  The only real difference is that site-status public
>       methods require a permanent key. We could combine the api by
>       adding a permanent-key parameter with a default of null.  If its
>       null we just store it in the session, otherwise store it in the
>       database. thoughts?

I've been mulling this over.  I think that messages and site_status are
definitely related, but different.  I'm ok with leaving them separate
for now.  They're similar enough that perhaps we could refactor out a
base class, but even then I think it's ok.  The APIs are clear enough as
they are.  I vote that we leave it alone for now.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Andy Staudacher-3]

On Fri, Sep 4, 2009 at 9:18 PM, Bharat Mediratta <bharat@...> wrote:

Tim Almdal wrote:
> I was just thinking... 2 things actually:
>
>     * Now that HtmlPurifier is in -contrib what type of upgrade code
>       should be there to reflect this move?
>
> What I was going to do is put up a site-status if HtmlPurifier was not
> installed (basically saying: "by default we encode html on output.  If
> you would like to render the html properly please  click <link to
> htmlpurifier codex page> to find more information.  Otherwise click
> here<link to gallery controller to clear the message> to accept this
> default.")

I don't think we don't need any upgrader code since this is just beta
code.

I think Tim was thinking about future upgrades, not the beta phase.

So you're running G3 with a purifier module, and you upgrade and forget to keep / download the contrib purifier module. What do you do.

We'll have to assume that you actually made use of the purifier before.  So at that point, your G3 will show lots of your contents (comments, descriptions, titles) garbled.

<your solution here/>

 

We can deal with the fallout in the forums.  I doubt too many
people are using HTML in their G3 installs anyway.  (maybe I'm really
wrong?)

>     * Is there any value in combining message helper and site-status

>       helper.  The only real difference is that site-status public
>       methods require a permanent key. We could combine the api by
>       adding a permanent-key parameter with a default of null.  If its
>       null we just store it in the session, otherwise store it in the
>       database. thoughts?

I've been mulling this over.  I think that messages and site_status are
definitely related, but different.  I'm ok with leaving them separate
for now.  They're similar enough that perhaps we could refactor out a
base class, but even then I think it's ok.  The APIs are clear enough as
they are.  I vote that we leave it alone for now.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]

[Bharat Mediratta]

Andy Staudacher wrote:
> I think Tim was thinking about future upgrades, not the beta phase.
> So you're running G3 with a purifier module, and you upgrade and forget
> to keep / download the contrib purifier module. What do you do.
> We'll have to assume that you actually made use of the purifier before.
>  So at that point, your G3 will show lots of your contents (comments,
> descriptions, titles) garbled.

This will apply to any/all contrib modules that you have installed,
right?  I'm assuming that any time you upgrade you'll have to deal with
upgrading any other modules at this point.

The gallery 3 philosophy here is: less is more.  I'm inclined to start
out by documenting the fact that when you upgrade, you should consider
deactivating all contributed modules first, and then try upgrading them
individually.

In specific cases where we really care, we could have the core module
look around to see what modules are out there, and if the versions
aren't good enough, we at least warn the user.  But I'm mostly inclined
to wait until a real problem surfaces before adding any kind of complexity.

-Bharat

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]