function setCustomTemplate($btHandle, $temp) {$this->customTemplateArray[$btHandle] = $temp;}

this is an area function that allows you to specify a template for the block, usually temp looks like 'templates/staff_listings'

leave off the php.

I don't know if this totally answers your question but it does at least let you delegate template selection to whatever the area wants(that your programmer(s)) specified based on your input.

a page type if that certain page type always does that stuff.

An aliased area block would be kind of neat, although I don't know how useful it would be. The code is on the forum somewhere, I posted it a few days ago.

The main point of this is ease of use for the client. So when they add a Block, there is a very descriptive item telling them the block that they can choose.

Content
Slide Show
You Tube
Staff Listing
3 Highlights
Side Highlights
etc.

Instead of just:

Content
Slide Show
You Tube
Highlights


I think in many cases, we can just specify the block type they can add to a block area like you said above, but there are instances where it would be nice to have the Aliased Block Name (When i say Alias, just meaning it knows to use the Highlight Block, staff_listing template)

While the duplicate code isn't so fun, I do see what you are saying.

Now would this "block type alias" be listed just like another block(the big ol list), or is this something where hey you want to add some content, great here are the 10 ways we have set up just for you to add content..and have some sort of accordion or slider or something on the "blocktype add" that could show an actual screenshot of the block's various ways of displaying content?

The block type(block) then based on the selection adds pertinent data fields w/ jquery and the controller handles that? It sounds like there could be some empty db fields or excessive db fields to accomplish this, but maybe for less used stuff you could just use a regex function and put in some wacky delimiter so stuff gets split up correctly (add a Salt to config on blocktype install maybe?)

That sounds kind of cool, and I could see the way the blocks are selected be grouped into sets by what they do to with an accordion on the list to lessen the scrolling.

hm. Sound cool?

I am not sure if we need to go that far. I simply would like to setup a new block in the block list and have it point to a Block & Template instead of just a block. I am not expecting a LOT of them, so the list would still stay small...probably would hide some of the stock blocks as well, so I don't think we need to do the whole accordion thing.

We have several circumstances that requires the exact same info. If it requires more or less parameters I think that would requires a whole new block. So the db stuff you speak of should not be an issue.

Header Text
Image
Content
Link (where you want it to go to)

The super simple way of doing this is to just duplicate the block in the blocks directory and just go through and rename each one. The disadvantage of this is it is more blocks to manage if we do have changes.

...while adding a block?
guess'd be a request...

I would rather not have that added step for the client. I would love for it to be like they are adding any other block from the list.

Right now to get it its own block in the block list I would have to duplicate the blocks and modify the view.php for each one.

Not a big deal to setup, but just kind of messy since they are all running off of the same base code.

so each block view's template is shown in the list as a separate block, so it would probably need a blockview template name and a blockview description(like a theme name and description) and if those are both present then it shows up just like any other block in the list.

That simpler? More on point?

That is the concept.

as I already wrote yesterday, I see the point of this idea too.

Having a more flexible "add block - list" would be nice. Would make it a lot easier if you're using a lot of templates...

Would have to be optional as not every templates needs to be a block though

It should be possible to simply overwrite the view function to check what area the block is inside of and choose the template based on the area handle. Then you don't have to worry about the customer picking it at all, they just add a highlight to an area and it shows the correct layout.

Area's can have attributes which you can dream up neat ways to use (like getThumbnail parameters is a fave of mine).

But there is actually a parameter you can add to the area as alluded to above:

var $customTemplateArray = array(); // sets a custom template for all blocks in the area

set by:

function setCustomTemplate($btHandle, $temp) {$this->customTemplateArray[$btHandle] = $temp;}

The functionality is there already :)

I actually have a copy of the highlight block that I'm playing with, and setting it in the area worked great. The only problem is that there is still an option to set a custom template, and if that's set then the block won't use the area's template.

I'm sure there's probably a way to disable the client from setting their own custom templates, otherwise it wouldn't be hard to change the blockview controller to use the area template no matter what the actual block is set to...

There might be a case where an area could have multiple types of blocks. (highlight layout 1, highlight layout 2, and staff listing highlight) They could all possibly be designed to fit in one area.

Mokay so we're saying:

"look, clients are simple. lets hide the type of functionality they're choosing when they add a block, and instead give them the label that we all know is in their head.."

I get that. It does feel like it would be even easier for some clients right out of the gate. It would certainly let developers create a more custom UI for the client's site. Fix it in time as it were.

This is part of where my concerns start with this idea. It's true that the block list needs better dashboard management, but the idea that we should just turn off everything a client didn't want at the time of purchasing the site and give them some very specific blocks that match the functionality/content requirements we defined at launch seems off to me. I think that's more how the traditional developer focused CMS's like drupal and joomla solve problems - build exactly to comp, turn everything extra off, congratulate yourself on making a well oiled set of switches for that complicated machine of a website you designed. It seems to me that assumes that a client's needs, or their willingness to learn are limited and won't change over time, which of course we all know isn't true. A little extra effort in understanding how things work in concrete5 today, might create many more opportunities for the owner to extend their site tomorrow (and pay you for help with it.) I don't like the idea of concrete5 being a G.I. Joe set, I like it being legos - you can always change what you're building..I'm worried about getting rid of all the basic 2x6 bricks and just giving owners the specific wagon wheels and weapons that emerged in later lego days.. ;)

I'm also concerned about creating a bunch of aliased blocks that are really functionally the same in specific installs. Seems like things could messy from a technical standpoint.. (you can no longer change a template on one of those blocks to the other once it's made, off the top of my head..)

All of that being said, I do think we need to revisit the management of the block list, and the way custom templates are chosen and previewed. I think in the big picture we'll be moving the custom template UI into the block details in another tab. There may be an opportunity to extend the block list UI at that time so we get the best of both worlds from the add block interface as well.

I understand your thought on that it is good for the client to really learn how their website works. I can tell you that the majority of our clients would rather NOT know. They just want it to work with the least amount of clicks and the least amount of work.

On the flip side I have clients that are in the industry, come from computer science backgrounds, are analytical, or are just curious. I would be more than happy to explain to them what is going on under the hood. The reality is, I just don't think many of them are in the latter group...that might be ignorance on my part,but from the past, they just want to see they can make changes and edits with out breaking anything.

I would not be limiting all of the other tools that make Concrete5 so great. (ex. a quick and easy way to add a video, add a form, add a content block, add a slide show, etc. I still want them to have all of those tools and be able to be creative on that end.

I have clients that would have no problems adding a highlight, go to the block and set a template. I have others that would say you want me to do what? (In reality, these people would probably be just editing what we created and not adding, but if they felt adventurous I want to give them the best experience possible.

This is not a pressing issue for me, just think it would be neat. Like I said above, if I have the circumstance where I think it is really important, I can simply take the main core highlight block we have and duplicate it into a staff listing block, side highlight block, full width highlight block, etc. The they have their quick and easy adding. (We now just have more to manage on our end if we need to make updates)