Separating Gallery level and album level configuration
|
vizion
Joined: 2007-03-25
Posts: 19 |
Posted: Thu, 2009-10-15 17:30
|
|
Ok In Gallery 3 can someone tell a good way of setting text attributes independently for Gallery level and album level. Ideally I would like to select all font features, including colour, for each element from a drop down feature list accessed from the administrative settings menu rather than by editing multiple files. I wonder if anyone has done any work on this. It would be so much better to be able to change such fundamental design features from a central location rather than onerously working to identify the correct place to edit the elememnts in the files. If such elements could be saved in a local configuration file it might also simplify version updating. Ideas please and if anyone has done something some practical examples would be helpful, not only to me, but to others. David |
|
Posts: 16503
No, right now you have to edit css files. You can figure out which files they are in simply by searching and reading the combined css file that Gallery generates. The beginning of each section of that file lists out where the css file is.
There shouldn't be a need to edit any css file other than screen.css and possibly the fix_ie.css file, as those should be able to overidden any other css settings.
There has been talk of having something in the UI for building themes or customizing the look more than what you can do now, but it's not going to ship with the first release for sure.
You can also override other parts of Gallery at the theme level:
http://codex.gallery2.org/Gallery3:Theme_Overriding
And to see an example of a chunk of another part of gallery being overridden take a look at the night_wind theme and in the css directory you'll see a themeroller directory. It's that easy.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 19
I do not think I have been clear enough.
Up until now code does not seperate between general coding and configuration.
I believe Gallery3 code provides an opportunity to develop tools that distinguish between configuration and general coding.
This could possibly start making a copy of *.css and generating *_css.txt files.
The next stage would be to devise a gallery3.conf file.
For example gallery 3 *.css files could then be created by processing the contents of a gallery3.conf file and modifying relevant *_css.txt files to produce an instance of gallery3 that meets the needs of the admin.
This would then mean that future versions of gallery three could incorporate updates, read the gallery3.conf file, and, using a stored config file, automatically generate a configuration that meet the local administrator's requirements.
This approach is well established, simple to administer and widely used and understood. If the process is well designed it lends itself to a tight integration between configuration process and system help. A good example of this is to be found with the way samba configuration and help files are integrated.
Here is an example of how it might be made to work:
in screen.css we currently have:
.gview {
background-color #fff
..
..
}
screen_css.txt would have something like:
[.gview {
background-color = $gview_background-color
..
..
]
gallery3_example.conf would include default values containing e.g:
gview_background-color = "#fff"
gallery3_my.conf would have admins modifications e.g. something like:
gview_background-color = "#000"
gallery3_conf.php would enable admin to choose the name of the active gallery_*.conf file
and forms that incorporated help and forms to input modifications and generate changes to gallery_*.conf files.
gallery3_conf_apply.php would generate *.css files by reading *.css.txt files and replacing $* with the appropriate entry from the chosen gallery_*.conf file.
s.
I see a big advantage in a structure like this because it would separate the configuration from basic code and facilitate future upgrade.
I am not saying this is a perfect way of doing it - I am just illustrating principles which could be applied.
Reactions invited
David
Posts: 22892
I am still not understanding what you are after.
Can you elaborate on: "I believe Gallery3 code provides an opportunity to develop tools that distinguish between configuration and general coding."?
And you explain what you mean? Configuration to me is various settings that can be changed via a user interface or as you perhaps suggest a configuration file.
And general coding to me is the 'backend' that the themer or module developer does not have to touch, the 'framework' ( kohana in our case) .
You might be thinking of a a module that could change the colors, similar to what G2 had in a colorpack module.
Perhaps you you can create a fork of G3 and show us an example of how you feel it should have been done.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 4
What I am saying is that the current coding approach for gallery3 seems to be based on the idea of multiple elements (code files) comprising a monolithic block. Elements within the existing monolithic block currently need to be changed to produce a local configuration.
What I am suggesting is to add to the Gallery3 framework a presumption in favour of removing actual configurable values from the monolithic block and replacing them by a placeholder and some form of lookup routine that extracts the desired values for run time from a configuration module. Let us call the files which incorporate placeholders the "pre-runtime code". Basically all runtime values should be regarded as data and stored in a data source {the configuration module} rather than in the run-time code. Therefore all values in the distributed code may be replaced by placeholders. The current values in the run-time code are incorporated in the default configuration. This would bring Gallery3 in closer harmony with Model, View & Controller architecture and lead to more flexible approach to future development strategies.
This implies final run time code would then be created by parsing the configuration files, extracting the configured run-time values from a configuration module and replacing the place holders in the pre-runtime code with values to be used at runtime.
The snippets in my previous post gave an example of how that could be done for a specific piece of code.
I think it is less of what should have been done but what can now be done. Gallery2, quite frankly, did not lend itself to such a systematic approach but the way Gallery3 is put together does.
If it were attempted at this stage it might not be too difficult to achieve using something like gawk to replace the values in the monololithic code with placeholders with a format rather like the one indicated in my earlier post. Gawk (for example) could then copy the surrounding code block into a help file, whilst simultaneously adding appropriate code to generate web forms rather like those used for the samba configuration tools. Current values in the monolithic code could be dropped into the the help file code blocks to create a permanent record of current default values. The forms would enable admins to enter replacement values and simultaneously show the code block from the help file. Additional comments could be added into the help file at source and by local admins. Additional facilities could provide an interface for 3rd party tools in the help file e.g
1. a color code reference chart when the value is a color or
2. a font chart for fonts
3. A dynamic form layout
So many things become possible when one has a dynamic configuration module
Output from forms would then be used to generate a new configuration file. When the user was satisfied by that configuration the output would be analysed by the parsing tool to check validity. The pre-runtime code would be copied and the placeholders changed for runtime value to generate the run-time suit. This would mean each admin could create multiple configurations and simply select which one to apply.
The beauty of this approach is that any admin could create a configuration which could be stored or shipped to a third party. This would facilitate debugging, testing on multiple production environments as well as provide a more secure framework for alternative configuration development. Any changes to the data presets needed for upgraded could be limited to modifiying local configuration files to conform to the latest upgrade. This would substantially ease both developers' and admins' workload at upgrade time.
As to having a go to create a branch- I will think about that - Time is the limiting factor for me the spirit is willing but I am careful about taking on too much.
David =-
PS as the application is dependent upon a database it might be easiest to create a configuration module which utilises a database for placeholders, accompanying code snippets, default values, comments, form parameters and tool links. The more I think about it the more attractive that method becomes.
Posts: 358
@vizion2000: Good thoughts, so why don't you add your thoughts to either of these tickets:
https://sourceforge.net/apps/trac/gallery/ticket/170
https://sourceforge.net/apps/trac/gallery/ticket/161 (probably this one)
And if you are really passionate about it, you could offer to try implementing it in your fork. If you do a good job then we can pull it back into core.
http://www.timalmdal.com
Posts: 358
@vizion2000: Further to, I have given this a lot of thought, in terms of how to clone and customize a theme. It doesn't make sense to do for every request (not sure if you are suggesting this) so it needs to be done in the administration screens as a one time customization. Not only do you have to get the screen colors (css), you need to get the icon pack colored correctly, and there are places that the colors are not specified in the css, but specified as part of generating the call to a flash object.
Welcome to our world, we do this as a hobby so it has to fit around our lives as well
http://www.timalmdal.com
Posts: 4
I do not think this is just about cloning a theme so I do not think it belongs in 161. Tt is about a total coding discipline and strategic decisions about where values are stored and how they are managed.
The current approach IMHO could be substantially improved. The theme approach, whilst it has substantial benefits over a no configurability option, seems to unnecessarily limit the benefits of galleries code base. These limited advantages IMHO only go small way towards a configuration approach and a coding practice that offers a clear separation between Model, View & Controller.
A configuration approach is an essential element in the MVC model. It means all values can be configured with equal ease, whether they are in .css,.php, .js, flash objects or wherever they are in the monolithic code. A big advantage is you do not have to scour code to find what you want. It means code is independent of administration and there solely for developers (hackers in or out of house! <chuckles>).
I know the concept of cloning a theme to achieve a configuration is deeply imbedded in gallery culture and I am aware that what I am saying may be heresy to some (never mind my head is used to being above the parapet!!)and is the current way of achieving administrative configuration. However it is arguably more of a coder's solution than a system adminstrator's solution. It is system administrators with a wide range of applications to manage who need to manage applications using independent configuration tools rather than code dependent files. That is why the majority of ported applications on **ix style systems have developed sophisticated configuration tools that are simple to administer and are ideally fully integrated with their help/support infrastructure.
The doctrine is that ideally no values "should" be "hard coded". Whilst the ideal is rarely fully achieved in practice it is possible to extract most of them in the way I have indicated and then take the pre-runtime code, integrate it with the values for the instance and you finish up with run time code that meets current requirements without administrators having to worry about coding.
This approach also means that when there is a bug all support requires is the bug report, a copy of the configuration file and details of the local environment. Any local coding 'hacks' should ideally be logged by the configuration tool which should parse the pre-runtime code, compare it with the runtime code and report any diffs that cannot be accounted for by the configuration module.
I am happy for you to copy these rambling and place them wherever you choose. You guys know best. Please let me know where you put them.
David
PS It looks as though I have 2 valid logins!!
Posts: 22892
We chose themes and modules because that is how other web based systems change appearance and layout. This method is well established and works. Sure it needs improvement from a customization point of view, but there is bigger issues to deal with before polishing can be done.
We only have limited development resources. If you feel strongly about going in a different direction please create a fork of G3 and make the necessary changes to add configuration files. The more effort you put into that the better understanding we will have on the direction you want to go.
I think that your efforts could go into developing a tool that would have all the values you need to build a view that the user desires as in this ticket:
http://sourceforge.net/apps/trac/gallery/ticket/170
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 19
I am thinking about this one and have some ideas on what I believe is achievable and how to create a web based generic configuration tool which might work for many theme/module based applications heavily dependent upon *.css files for managing configuration changes.
I envisage:
A first stage which provides the means for a user to be able to upload a batch of .css files to an on-line service. After validating the css code and generating a "prettied" and indexed version of it the service could generate a downloadable *.config file based on the contents of the *.css files. Those *.css files would incorporate data in comment fields added to the "prettied" files by the service. The user might then modify the configuration file using a web interface that could incorporate help directives similar to those used with the samba toolset. I have hacked a bit of code which has convinced me the conversion of *.css files based upon a simply formated config file is a practical objective. There is therefore a real propect of building a downloadable configuration toolwith the capoacity to generate a new set of *.css files implementing changes based upon entries in a simply formatted *.config file.
It would be good if the help directives could be designed to facilitate community involvement and on -line updating. In the form of "This tool does not know what happens if this parameter is changed. If you know please comment here!" Or "Here is community help - please add your comments if you can provide more insight."
Some thought would be needed on how to handle any changes to the core code which necessitate updates to configuration file format and .css files. A simple set of guidelines would be needed for developers to ensure they could take full advantage of the service. A cvs system would probably do the ground work.
All for now
David
Posts: 358
The approach sounds overly complicated to me. Having complex config files are a "pain in the ass" at best and recipe for disaster at worst.
Have you even read ticket #170? Or tried the WordPress theme generator?
We are using one its called git. If you would like to fork the project and try it out... "fill your boots, if it something that we can use, we can always re-integrate into the master fork.
Thanks for your input, but the core team is focussed on delivering the initial release and don't have time at this point to rethink the theming sub-system
http://www.timalmdal.com
Posts: 19
Not half as complicated as multiple css interacting with multiple programming script languages!! Maybe my team and I have more experience of using config files which enable us to manage thousands of applications all of which use configuration files. The current approach is used simply because css has no variables in the w3 standard.
Certainly they are not as much a "pain in the arse" as traipsing around poorly documented multiple css files which require administrators to be able to interpret which colour code iosrefering to which bit of the display on what occasions. That approach maybe good for coders but is ba poor resource for administrators.
Yes but it is extremely limited and not half as flexible as a good configuration system could achieve given the tools to develop. Furthermore a decent system should work not just for Gallery3 but for most theme based applications. That would mean know one config system and your knowledge is transferabble across the board.
I do not think you have read carefully. The approach means you would not have to rethink anything!! The configuration system operates as an independent tool which could be used as a user management layer for the app. If the development team wanted to take full advantage of it then they could build upon it when the appropriate development stage has been reached.
I have a name for the project. DByCIS [Pronounced "DeeBeeCeease"] Acronym for Don't Bury Your Configuration in sand!
<chuckles>
david
Posts: 22892
Please develop a config system with your team. Show us how simple it is in a fork. Talk is cheap and we have limited resources to develop a config system. Since you have done this already with your team for other things it will be a lot easier for you to develop since you have done it already and we have not.
As talmdal said we don't have the resources to work on this at this time.
That means if it is important to you as your post(s) suggest and you have a team that has done this in the passed, then it is up to you to find the time since we don't have time or interest in doing so at this time.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 19
I do not think I have anywhere suggested you should do it. I have only pointed out the consequences of current configuration techniques, their lack of of portability and the disadvantages for system administrators.
My conclusion is that the way configuration is currently managed (not just for gallery but also for a lot of other similar projects) is far from satisfactory. My purpose now is discuss better ways and demonstrate that there is no reason to assume existing methodologies are good as they might be. IMHO the only talk that is cheap is either complacent or defensive. The most valuable talk in a development environment is positive criticism which has the potential to move methodology forward.
Frankly I would not be bothering to contribute if I felt gallery3 did not deserve a better configuration toolset that it currently has.
Whilst I appreciate that NIH may be a factor affecting some responses I do acknowledge that the value of new approaches can only be appreciated in theory until they have been demonstrated in practice. However they need a lot of careful work in the former stage before reaching the latter. I have have seen a lot of software development time wasted or or being ineffectively applied when insufficient time and effort has been devoted to developing a sound theoretical basis.
IMHO the lack of good configuration tools for the many projects, like gallery, which depend upon the manipulation of raw code files rather than plain text configuration files, is an example of what happens when current practice is adopted without critical analysis at the design stage. For most application in this genre that has unintentionally lead to an innapropriate balance of development effort between application development and the provision of administration tools for managing the application. The effort has therefore been focused on a rush meet requests for enhanced application functionality at the expense of attention to providing administrative ease.
IMHO there is a need to shift the balance. That can be done either individual application by individual application or by a group undertaking the development of a generic toolset which could be used, in common, by a large number of applications of this genre. I am exploring the latter as it would seem to offer the greatest amount of communal benefit per unit of development effort.
This is a not intended to be read as a criticism of the gallery team because the failure is widespread in this genre. The gap is now only being recognised. It is not surprising the recognition is occuring now because applications of this comparatively new genre [multi-language/theme/css approach] have been spreading widely. This means more and more systems administrators are faced with the problems I identify.
The lack of variables in css has also been a delaying factor. If css variables were available then we would probably not be where we are today. I am just trying to encourage a recognition of the implications which largely stem from that limitation.
In the meantime a little bit of thoughtful encouragement plus a genuine recognition of the limitations of current configuration tools is I feel appropriate. The contribution of a few constructive ideas [outside the current box] and a modicum of respect during the theory building stage would not go amiss <chuckles!>.
David
Posts: 128
For my particular theme, I have introduced the use of variables in screen.css. This is primarily for being able to select different color schemes with ease, but can be applied to just about any parameters values in the css file.
I created a screen.defs which contains all of the scheme and variable definitions.
Then created a screen.master which has all of the normal css with the variables in place.
There is also a class enhances_css.php that, in effect, uses the .defs file, modifies the .master and outputs a new .css file
It does this any time that the .defs or .master is newer than the .css file, and is invoked by invoking the class at the beginning of page.html.php
None of these changes are outside of the particular theme, but could be introduced as standard part of every theme.
Attached are samples of the files to do this. They are version 0.2 and still in rough developement shape (ie: no docs).
Martyn T. Griffin
Posts: 19
Looks like you are following a similar approach (almost the same terminology too!!).
The next challenge is to develop a tool which can parse all existing files, determine which parts of those files could be variables and create a default config.
It looks as though you have done something similar to my "proof of concept" .i.e. creating a method of introducing "variables" into skeleton *.css files and a routines that replaces variables with values. I am pretty sure this is the way to go.
David