Forum OpenACS Development: Master explanation

Collapse
Posted by Malte Sussdorff on
Could some of the OpenACS style gurus give a good definition of:

- blank-master
- site-master
- default-master

And what they are used for. I have tried to give a preliminary one at http://cognovis.de/developer/en/custom-layout but obviously that needs more fleshing out.

Collapse
2: Re: Master explanation (response to 1)
Posted by Avni Khatri on
Hi Malte -
  • default-master --> outputs the header (who's online, login, logout, pvt/home links) and footer html along with the context bar. This is usually the template I modify and the one I use as the value for the DefaultMaster parameter for my subsites
  • site-master --> outputs js necessary for xinha and other rtes
  • blank-master --> outputs the html head and body tags, content within <head></head>, links to css and other script files, meta tags, body tag attributes
Also, is there a reason why we have 3 master templates? It seems like an unnecessary complexity though I guess it does make things a bit cleaner.
Collapse
3: Re: Master explanation (response to 2)
Posted by Jim Lynch on
Ok, good, so that's what they do, that's half of the answer... but (historically, big-picture, thinking about the graphic designer), what are they for?
Collapse
4: Re: Master explanation (response to 3)
Posted by Janine Ohmer on
This was something Lars did. He explains his reasoning here:

https://openacs.org/forums/message-view?message_id=154693

I've never cared much for having so many files to keep track of, but it has been this way for a long time now.

Collapse
5: Re: Master explanation (response to 4)
Posted by Jim Lynch on
Thanks Janine :)

This is what I've been looking for for a fairly long time...

Mentioned therein are "skin packages"... are there any? are
they what you might call "complete" and "fully functional"?

Collapse
6: Re: Master explanation (response to 5)
Posted by Janine Ohmer on
There is a package called skin in CVS, but I don't know anything about it. It looks like it predates Lars' work on this, so probably not relevant. Other than that I don't know of any, sorry.
Collapse
7: Re: Master explanation (response to 1)
Posted by Malte Sussdorff on
I know that Lee was / is doing some reorganization on the templates. I would prefer if we could merge site-master and blank-master into an openacs-master, which is something that is not going to change often.

The default master should then set *all* CSS files like

multirow append header_links "stylesheet" "text/css" "/resources/acs-templating/lists.css" "all"
multirow append header_links "stylesheet" "text/css" "/resources/acs-templating/forms.css" "all"
multirow append header_links "stylesheet" "text/css" "/resources/acs-subsite/default-master.css" "all"
multirow append header_links "stylesheet" "text/css" "/resources/acs-subsite/site-master.css" "all"

I would TIP this and implement it for 5.4, but would others in the community agree ?

And while I am at it, wouldn't it make sense to only have one "main.css" which includes all the other CSS files, so we could hand over a complete directory to a designer with all CSS files in them?

I would then go one last step further and create a CR Type "CSS file" which allows us to keep multiple CSS files in the database (using the cr-content to store the file and use two fields "type" and "file-name" to store the type (e.g. list, form, ....) and the actual filename on the harddisk) and have a designer edit them online. Once done he can say "save to file system" and be done with it.

Collapse
11: Re: Master explanation (response to 7)
Posted by Don Baccus on
Please, let us finish what we've begun before you go off trying to muck it up with a new TIP which I'll immediately vote "NO" on.
Collapse
12: Re: Master explanation (response to 11)
Posted by Malte Sussdorff on
Well, then finish what you have begun and state how and why you are planning to do that. Make a roadmap for it. And open it to discussion outside the .LRN community. If you have plans that need to be finished, that is not really documented. Maybe Lee is finished, maybe he is not. There is new templating work coming on (posted as a sitenote), but it is neither discussed nor TIPed. At least not in a place usually used for discussion.

So please bear with me when I voice concerns I heard from multiple parties and if you want to vote "NO" to any TIP that is fine, but stop using that as a threat to kill any discussion before it had the time to take off. Instead I would have expected you to post why it is a BAD idea, what your plans are for solving this scenario and being a little bit constructive.

Collapse
13: Re: Master explanation (response to 12)
Posted by Iuri Sampaio on
Very oportune this thread.
We, me and Robert Taylor from Canada, are working on somehitng on this line.
Malte,
I believe I foresaw your ideas. I've played a bit with "/www/blank-master", "/www/site-master", /www/default-master", and also /packages/acs-subsite/www/group-master

I created a peculiar master page what i called "openacs-master". take a look at: http://69.67.174.135:8000

Collapse
14: Re: Master explanation (response to 13)
Posted by Iuri Sampaio on
PS: Take a look at Zen menu. i put set it up at openacs website without needing .LRN installed
Collapse
15: Re: Master explanation (response to 13)
Posted by Malte Sussdorff on
Hey, can you send me your openacs-master? That is really nice and I could use it in two of my websites that do not run .LRN
Collapse
16: Re: Master explanation (response to 15)
Posted by Iuri Sampaio on
sure malte,
we wonder if we could upload it to cvs.

I created an api at /acs-subsite/tcl/subsite-procs, and made tabbed menu as a parameter of mainsite. Then i call the api on openacs-master page

exactly as it's on zen pkg.

what would be the best way send you?

Collapse
17: Re: Master explanation (response to 16)
Posted by Malte Sussdorff on
Make a commit to CVS on HEAD and I will check it out and others can then rip my head off it it does not meet the standards and need to be rolled back.

Just make sure that whatever you do, the default behavior is still the same but it sounds like you did this already.

Collapse
18: Re: Master explanation (response to 16)
Posted by Don Baccus on
Please explain in more detail what you've done, and please don't commit until afterwards.

Currently core has separate masters for tabbed and untabbed styles, and it sounds like you've added a parameter that partially duplicates or does this in parallel or something?

Collapse
20: Re: Master explanation (response to 16)
Posted by Malte Sussdorff on
Iuri, just provide a diff from acs-subsite on HEAD and the /www directiory. Open a ticket in the bug tracker, provide the diff as a patch. Post the link here. I will test it and report back. Dave can then incorporate this into his work (or not). If that is too much work for you, just send me the changed files via E-Mail 😊. I think Don is right, do not commit to HEAD as we do not have a "playground" which lets us revert changes anymore. Sorry for me making this suggestion which would have saved us some work.

Don, with regards to openness I would have expected something like https://openacs.org/xowiki/templatehead. Furthermore, before it is incorporated it definitely needs a TIP or am I mistaken there? Same should apply to any changes with the default master and new structures how they are split up, when they are joined, which CSS are going to stay, where they are going to stay, what the logic is behind all this and so on and so forth.

Knowing how many sites broke on upgrade to 5.3.1 I am really weary about any changes being done without proper explanation what needs to be done. And I have yet not seen a page which describes what needs to happen to keep your 5.3.0 design when doing the upgrade. But maybe its just me and anyone I work with who ran into that issue and it works fine for everybody else, no explanations required.

I can only say that I recommend to be weary of OpenACS upgrades of the master templates at the moment and keep them in your own directory as described at http://cognovis.de/developer/openacs-customizations. That at least saved me from manually fixing 4 sites after running into the upgrade problem, broken styles and so on on the old ones. Guess why I made sure you can have the "standard.adp" form template reside in a different location than acs-templating/resources/forms/ in the first place? Because it changed so much that none of the clients I had where happy, but where not willing to pay the CSS guy to do the ammendments which previously where done in the tables in the divs now.

I am not saying this was a wrong move (going to DIVs and so on), but for a minor release this was a heavy move. And without proper documentation on "how can I keep my customizations when I upgrade to 5.3.1" it is hard on people.

Collapse
21: Re: Master explanation (response to 20)
Posted by Iuri Sampaio on
The whole upload CVS stuff
turned into very big deal deal. Take a look at this site,
It seems we will have more discussion a lot about new styles , DIVS, SPANS this and that ...
Take a look at http://69.67.174.135:8000. The white dog is out.

Malte, I will just send them by email.
One thing, you wil need to copy the pages, go to the code, create the parameters and upload the API at your system.
I believe you know well about it.

Collapse
22: Re: Master explanation (response to 21)
Posted by Iuri Sampaio on
I see /acs-subsite/www/group-master, from HEAD, now is a lot diferent from the past.
Did someone take the features away?
Collapse
19: Re: Master explanation (response to 12)
Posted by Don Baccus on
Isn't the OCT "outside the .LRN community" enough for this stuff? Since lee, daveb and I discussed it there as well as at .LRN honchos meetings?

"Instead I would have expected you to post why it is a BAD idea, what your plans are for solving this scenario and being a little bit constructive."

I didn't say it was a bad idea, I said PLEASE WAIT.

Daveb's finishing up Lee's work, and I'll work on integrating packages for 5.4.

Collapse
8: Re: Master explanation (response to 1)
Posted by Dave Bauer on
Malte

I'd like to be a little more clever about it.

The reason for multiple files is to keep the CSS in the right place.

The trick would be to compile a master css from the appropriate files when necessary.

It would be easy to do this once Lee's work on template::head is complete. Hamilton is looking at completing this work.

The advantage is that you still get modularity and the system can consistently manage the files for you.

I think allowing editing of CSS files from the web interface is really a seperate feature from this since the end result is a file in the filesystem the rest of the features only need to know the location of the file and it should not matter where it came from. I'd also think most designers would rather upload a complete file than edit it in a web browser.

Collapse
9: Re: Master explanation (response to 8)
Posted by Malte Sussdorff on
Sorry, when I say "include" i meant really include with a reference, not physically copying all content there. Obviously we should keep the files separate. No need to compile the master.css in my opinion, CSS after all is smart in including other files and it gives you much leeway with the Webdeveloper edit function.
Collapse
10: Re: Master explanation (response to 1)
Posted by Dave Bauer on
Malte,

Making 20-30 requets to render one page is REALLY SLOW.

If you add in all the CSS, JS, Icons, images, logos etc, there probably does need to be a way to speed things up.

I'll discuss it in another thread.

Collapse
23: Re: Master explanation (response to 1)
Posted by Robert Taylor on
i think you guys should all just hold off on patching anything.

even submitting a patch via bugtracker might be premature, there are FAR too many things happening simultaneously - and none of you really know what we are up to and why.

just aheads up to everyone wondering, here is what i hired iuri to help me with in terms of proposing a redesign of the openacs website:

1. LESS FUCKING TALK MORE FUCKING CODE. i'm one of the biggest culprits of this, i talk a whole truckload but i've not managed to accomplish dick. i'm just putting my foot down and getting a redesigned website up and running for my own amusement. talk is cheap, code talks.

2. JUST GET A WEBSITE UP AS FAST AS POSSIBLE USING STANDARD OACS PACKAGES. actually, thanks to gustafs amazing work, xowiki really pulls oacs together in a whole new way. we have been able to replicate the entire website with practically stock packages. of course a few minor "TWEAKS" are required to actually get stuff to work, these "TWEAKS" are catalogued and will be made available to everyone in the oacs community and for oct and core devs to consider for inclusion into oacs. maybe we are redoing stuff that already exists, maybe we are patching in good ideas, i don't fucking know but i also don't fucking care. i want something up that is functional and that works and something we can all poke a stick at. you guys will then turn around and tell us what to fix, what to change, how to change it, what we did wrong, etc.

3. SUBMIT THE SAMPLE DESIGN + CHANGES FOR CONSIDERATION TO OCT, CORE DEVS AND THE ENTIRE OPENACS COMMUNITY. we are almost done, i just have a FUGLY placeholder for the home page. once i'm done the graphics on the home page we will submit the site for everyone to see and critique. its 1/2 redesign (that is its not a full redesign just a cleanup) and 1/2 polishing up some rough edges to get an out of the box setup running. you guys will comment on the look and feel (1/2 design) and the technical changes we had to make to actually make it happen (1/2 polishing up). while it is our hope you will like our work and our ideas, we will change whatever you want and align with whatever is happeningin oacs core to get it done.

4. OUR GOAL IS TO HAVE THE OACS PROJECT EAT ITS OWN DOG FOOD. WHAT WE HAVE AS OUR WEBSITE IS WHAT A NEW USER SHOULD BE ABLE TO INSTALL IN A FEW MINUTES WITH STOCK PACKAGES, ABSOLUTELY NO CODING AT ALL. at least that is our hope. the rest of the oacs community might have other ideas but this is ours and we just putting it up for critique. it will be up to you guys to decide if its a good idea, bad idea and whether any of it is absorbed into the project. at least now i know what it takes to get an oacs website up and running, how fast and how much effort.

so, lets hold the ship nice and straight. i just haveto finish my end of the bargain and thats actually completing the main home page graphics as iuri has completed most of the work (nice job dude).

the last thing that will be needed is to mount project manager, but that isn't quite ready yet. malte, you and i need to chat about that a bit, you fixed up everything i requested but i would like to revisit a couple of ideas, namely the initialization of the first project and the main pm view. once we have a decent pm up and running, we can hook up xowiki to it and use that to document a roadmap if one doesn't exit (i don't know, haven't looked) maybe? i know i will use it for the documentation project and to start a bit of a marketing hype thing in the community.

so feel free to visit iuris link, ignore the fugly gfx i'm working on that, but we will have a presentable sample ready for everyone shortly.

Collapse
24: Re: Master explanation (response to 1)
Posted by Ben Koot on
Robert,

You talk sense, here's what I create without coding, despite some bugs, it works out of the box and let's me set up a web presence in a matter of minutes during a simple chat with my client.
http://www.villagetalk.net/xowiki/index.
http://www.villagetalk.net/samaritan/binwiki/
It may not win a design contest, but my users are really happy with the tools. I am looking forward to your finished set up and pm integration, as that's what I realy miss at the moment.

Cheers
Ben

Collapse
25: Re: Master explanation (response to 1)
Posted by raananschwartz raananschwartz on
Nice one robert!

_____________
iplobster.com
_____________