Need one collection/page with two views or page types

Permalink
Sorry if my terminology is off here...

I want to have one page with about 30 attributes, and two different page types to display that data in very different ways. How can I do this?

I was imagining programatically switching the page type with a controller method using View->url()... is that even going in the right direction? Do I need two themes?

Any pointers will be much appreciated!

kirkroberts
 
ijessup replied on at Permalink Reply
ijessup
Now this is my personal opinions, but...

I would just create a new block that displays a page's attributes, then create templates for that block.

Create a conditional in the url... like:http://www.site.com/index.php/this_is_my_page?bID*BLOCKID*=*BLOCKTE...

So... it would look like:http://www.site.com/index.php/this_is_my_page?bID9999=list_view...

So when the controller sees that $_REQUEST['bID'.$this->bID] is set, you can get that variable and adjust the template respectively.

---------

You could do that same thing with a page type (essentially), but if you do this with a block you have more freedom as to how and where you can display the information.
kirkroberts replied on at Permalink Reply
kirkroberts
Thanks for the idea! Very interesting. That would be a massive block (almost the entire page). Unfortunately I'm not sure that would work as the entire page is changing between views, not just a discrete area. This is why I was thinking about two page types. I don't foresee the data being reused elsewhere, so that's not a concern, and I am already primed to use the auto-nav and page list blocks to show the many pages that hold these data sets.

But I really appreciate you taking the time to make the suggestion. I bet that technique will come in handy!

I'd still love a pseudocode tip on how to programatically switch page types, if anyone can help with that.
ijessup replied on at Permalink Reply
ijessup
No prob! :D

In that case, rather than an additional page_type, I'd suggest an additional theme.

Unfortunately I don't have a good analogy as to why I think that, but... because you only want to change how the page looks, then create a conditional like I mentioned before... but in this case just add this to the page_type's code to select the different theme:
$view = new View();
$view->setTheme('theme_handle');
$view->render($this->controller->getCollectionObject());
That's completely untested and off the top of my head...

Check out this file for more info: ~/concrete/libraries/view.php
kirkroberts replied on at Permalink Reply
kirkroberts
ijessup: thanks so much for your time and expertise!

Right now it's unclear to me how it will work by putting code into the page_type.php will redirect to another theme, but I think I have enough info to start experimenting.

I see now there is a free theme switcher block in the marketplace. Not exactly what I need, but it may be handy as a resource.
ijessup replied on at Permalink Reply
ijessup
To be clear, are these 30 attributes on only one page? or do you have multiple pages with which you fill out the 30 attributes?
kirkroberts replied on at Permalink Reply
kirkroberts
It's a portfolio of real estate properties, so it will be 30 attributes per page and about 30-40 pages to start. The client will be admin'ing it. I'll probably set up a dashboard page for that so I can arrange the fields just so (if only one could arrange custom page attributes.... sigh... ). Big photo gallery for each property.

One view will show some of the photos and attributes, the other will let it all hang out, in a very different presentation.

I looked at Tony's real estate package and it doesn't seem like a good fit.
hereNT replied on at Permalink Reply
hereNT
You can (somewhat) control collection attributes with sets, it's a little complicated though. I'd recommend the dashboard page for your admin stuff.

I'd do one page type, with a simple if/else statement checking for a request variable, then a link to change that variable:

<?php if ($_REQUEST['display'] == "photos"){
// slideshow view code
} else {
// full view code
}
?>


I'm currently installing a new OS so I can't look up how to do the conditional in the URL, but I think you can use $this->url(); I just don't know syntax.
kirkroberts replied on at Permalink Reply
kirkroberts
hereNT: well, that is a fresh breath of simplicity. With one page type I could easily use a controller action/method to affect the view (like a lot of single pages do). That would make for slicker URLs without query strings.

Very cool.

I appreciate everyone's help... this is starting to gel in my brain.
ScottC replied on at Permalink Reply
ScottC
do a page type, wrap the various areas in conditionals, in your page type controller, analyze the request task, show the given section.

If the page is in edit mode, and the user can Admin the content, then show every single area(so you can get all the data in on one page, IE you can Add to every area since none of them are hidden.

Then in your controller you would wnat to do $req = Request::get();
if($req->getTask() == "gallery" you would do $this->set('ShowGallery',true); in your page type, you would have if($userCanAdminPage || $showGallery) $a = new Area("Gallery"); $a->display($c);

That allows conditional content somewhat crudely, but it works really well.

I would like to write a big photo gallery app one of these days :), something like slideshowpro director.
kirkroberts replied on at Permalink Reply
kirkroberts
ScottC: great ideas, thanks!

SSP Director is an amazing image/video CMS. I've used it for a bunch of sites, and even once in conjunction with c5. Bringing that kind of functionality to a c5 dashboard app would be impressive.
CodeOtaku replied on at Permalink Reply
CodeOtaku
You need to index the 30 attributes in some way so that on the views for each page, some php code can extract the relevant attributes.

What I think you need is an input form for your data which puts it into an array where the input form has a selector drop-down box for the page, a form of all the fields of input text and a submit button.

Then this info is assembled into an array of serialized data and saved to a page attribute.

Then, on each page, this data would be extracted, the relevant data for the particular page isolated, and displayed accordingly.

What you seem to be doing is bypassing the need to code a custom solution where you need to index your input data according to a particular page. So at least, you need a prefix to each data item indicating which page it refers to such as 1-data for page 1, 2-data for page 2 etc.

Actually, what you need is a database table to house your data and a bunch of custom code :)
kirkroberts replied on at Permalink Reply
kirkroberts
WPTycoon: thanks for your thorough reply. I almost understood half of it :-)

Using c5's built-in page model and custom attributes makes the most sense to me. No need for creating special database tables. The building blocks are all there in c5... I'm just looking for the best way to put them together. ijessup and herent are speaking my language.