Koha.next: Consolidate OPAC themes?
+1 for classes and unique IDs! Agreed that each theme should just be CSS and presentation Jscript. I'm also a fan of not passing system preferences to the templates from individual Perl scripts. They're global system preferences, no? I think we should treat them as such. Less code and more simplified development :D. +1 for standardization and consistency as well in regards to naming. (For 3.8, I remember Paul being really good about hounding people regarding naming conventions.) I'm not sure what I think about using ajax based widgets. In theory, I like the idea, but I don't think it's a good idea for all of Koha to bust if someone has their Jscript turned off. Includes might be a decent compromise though. I think we do need to cut down on how much code is duplicated across different modules (or even in the same module in some cases). David Cook Systems Librarian Prosentient Systems P/L ABN 31 078 409 168 72/330 Wattle St, Ultimo NSW 2007 tel: 02 92120899 fax: 02 92120885 dcook@prosentient.com.au -----Original Message----- Date: Wed, 10 Apr 2013 07:23:04 -0400 From: Kyle Hall <kyle.m.hall@gmail.com> To: MJ Ray <mjr@phonecoop.coop> Cc: Koha Devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha.next: Consolidate OPAC themes? Message-ID: <CACpVHfxMAyDxOypPRUYX3eAhSR_a7HX0=+Pqfft82H00Qiq+jQ@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" This these have been my thoughts exactly as well. I think it would be best if the templates were pure unstyled html that are well classed and all elements should have unique id's as well. Each theme should just be css and presentation javascript. In addition, I think we should completely remove the necessity of passing in system preferences to the templates from perl scripts, and switch to using a TT plugin for accessing system preferences. Ian also has a very good point about standard naming conventions. It would be great to get all the variations on naming wrangled into one standard version. Another thought I've had that would simplify Koha and keep it more DRY would be to implement ajax based widgets. For instance, both circulation.pland moremember.pl display a list of holds in a tab, but each is a separate implementation. If we just made this code a widget ( or even just a .inc file with all the required html and javascript ) we could reuse it on any page we wanted to. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )
+1 for includes as well. If we have to show it in the same way on more than one page, it ought to be an include. Liz On 11/04/13 11:42, David Cook wrote:
+1 for classes and unique IDs! Agreed that each theme should just be CSS and presentation Jscript.
I'm also a fan of not passing system preferences to the templates from individual Perl scripts. They're global system preferences, no? I think we should treat them as such. Less code and more simplified development :D.
+1 for standardization and consistency as well in regards to naming. (For 3.8, I remember Paul being really good about hounding people regarding naming conventions.)
I'm not sure what I think about using ajax based widgets. In theory, I like the idea, but I don't think it's a good idea for all of Koha to bust if someone has their Jscript turned off. Includes might be a decent compromise though. I think we do need to cut down on how much code is duplicated across different modules (or even in the same module in some cases).
David Cook Systems Librarian Prosentient Systems P/L ABN 31 078 409 168 72/330 Wattle St, Ultimo NSW 2007 tel: 02 92120899 fax: 02 92120885 dcook@prosentient.com.au
-----Original Message-----
Date: Wed, 10 Apr 2013 07:23:04 -0400 From: Kyle Hall <kyle.m.hall@gmail.com> To: MJ Ray <mjr@phonecoop.coop> Cc: Koha Devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha.next: Consolidate OPAC themes? Message-ID: <CACpVHfxMAyDxOypPRUYX3eAhSR_a7HX0=+Pqfft82H00Qiq+jQ@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1"
This these have been my thoughts exactly as well. I think it would be best if the templates were pure unstyled html that are well classed and all elements should have unique id's as well. Each theme should just be css and presentation javascript.
In addition, I think we should completely remove the necessity of passing in system preferences to the templates from perl scripts, and switch to using a TT plugin for accessing system preferences.
Ian also has a very good point about standard naming conventions. It would be great to get all the variations on naming wrangled into one standard version.
Another thought I've had that would simplify Koha and keep it more DRY would be to implement ajax based widgets. For instance, both circulation.pland moremember.pl display a list of holds in a tab, but each is a separate implementation. If we just made this code a widget ( or even just a .inc file with all the required html and javascript ) we could reuse it on any page we wanted to.
Kyle
http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
On Wed, Apr 10, 2013 at 7:42 PM, David Cook <dcook@prosentient.com.au>wrote:
I'm not sure what I think about using ajax based widgets. In theory, I like the idea, but I don't think it's a good idea for all of Koha to bust if someone has their Jscript turned off. Includes might be a decent compromise though. I think we do need to cut down on how much code is duplicated across different modules (or even in the same module in some cases).
Yeah, I keep forgetting that we need Koha to function without javascript ; ) I think includes will be the way to go. We can even make the includes more function-like by defining blocks within the .inc files so we can pass in different data. That way we can use the same block for different data loops on the same page. http://www.template-toolkit.org/docs/manual/Directives.html#section_INCLUDE Another thing we might do to simplify is to use TT's WRAPPER directive. We can put everything from <body> up, and the bottom include in the wrapper. We can then include a block that gets defined within a given template for including javascript or other .inc files within the header. Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )
Is there anyone who disagrees that we should merge the two themes and have only one in the future? Is the CCSR theme design the one every one likes better? If not, what features of each should be preferred? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
I think the biggest issue with just ditching the prog opac theme is everyone who upgrades will lose their customizations, and have to re-do them. However, if the prog theme has a specific sunset release, it will give everyone time to re-customize and hopefully patch the theme for any customizations that currently work on prog but not on ccsr due to lack of id's or classes. http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Thu, Apr 11, 2013 at 9:04 AM, Owen Leonard <oleonard@myacpl.org> wrote:
Is there anyone who disagrees that we should merge the two themes and have only one in the future?
Is the CCSR theme design the one every one likes better?
If not, what features of each should be preferred?
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
A bit late to the discussion here, but comments below: On Thu, Apr 11, 2013 at 9:04 AM, Owen Leonard <oleonard@myacpl.org> wrote:
Is there anyone who disagrees that we should merge the two themes and have only one in the future?
Is the CCSR theme design the one every one likes better?
It does seem to get the most oos and ahhs in demos/training
If not, what features of each should be preferred?
That said there is no way to add a header image to CCSR - something above the search box like you can in prog. The opacheader (unless it has been changed) only appears to the right of the search box - not at the head of the page as I would expect it to. That is a feature of prog that I think needs to be incorporated into CCSR. There are other preferences that also seem to have been moved/removed from CCSR (all have bugs reported) but that's the biggie that I can think of right now.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
participants (6)
-
David Cook -
Kyle Hall -
Liz Rea -
Mason James -
Nicole Engard -
Owen Leonard