Admin Extension on Page-Edit

This is a forum to suggest new features for mojoPortal. 

This thread is closed to new posts. You must sign in to post in the forums.
10/11/2006 11:05:50 PM
Gravatar
Total Posts 3

Admin Extension on Page-Edit

Hi,

I've been using the mojo application for a few weeks now, and assesing how we can implement quick modular components that match the customers needs.  For the most part it has been very good, and 80% of our needs are already met.

We have certain sites customers that would request designs that do  not fit well with the mojo design in it's current form, in particular the layout restrictions of three columns would be restrictive.

With this in mind, I was wondering if you have any future iterations where you are thinking of updating/changing the administrative page edit process in some way?

From out standpoint the approach we would look at is to allow the edit module to investigate the master page and provide a dynamic list of columns that modules can be added to.  Currently we add new panels to the master page and manually configure to allow modules to be placed in these panels.

If you are not looking at this appraoch (I know you're investigating Web Parts at the moment which would also work in a similar manner with the zones), and if we can get a go-ahead to start a small project to adapt the admin page, would you be interested in the results that we produce?

Paul.

10/12/2006 3:55:47 AM
Gravatar
Total Posts 18439

Re: Admin Extension on Page-Edit

Hi Paul,

If you come up with a better approach I'm interested in seeing it.

However the current approach is not limited to 3 columns, any page can have 1, 2 or 3 columns so the limitation is only that you can't have more than 3 columns. I do not consider this a limitation since I have never seen a site with more than 3 columns that I considered a good design.

The advantage of the current approach (at least with the included skins) is that the css for each page adapts to 1, 2, or 3 column layout based on whether there is any content in each of the 3 columns. And it does this using css layout instead of table layout and is xhtml compliant. If you come up with something even more flexible and adaptable I'm happy to see it. If I agree it is a better solution I will be glad to incorporate it in mojoPortal.

I've completed the implementation of WebParts several releases ago. The MyPage feature allows users to create personalized pages from any site content flagged as available for MyPage.

So, if you can show me a proof of concept for flexible layout that is better than what we have today I'm all for it.

Joe
10/12/2006 4:23:57 AM
Gravatar
Total Posts 3

Re: Admin Extension on Page-Edit

Thanks Joe,

I think the main reason we need a more flexible approach is because our sites are less portal based and more oriented towards CMS type applications.  I do tend to agree that by and large a threee column approach is the best for 99% of sites, but ultimately customers are "always" right :)

If we get the go ahead to move forward with a solution, I'll keep you informed on what ideas we come up with.

I've had a quick play creating a solution by investigating the master page and simulating content areas from the page... I also created a table to hold the content ID details as FK for modules...  Havent got far enough to really test the idea yet though, but managed to pick up content holders that were applied in dynamic positions.

Thanks again,

 

Paul.

10/12/2006 4:57:09 AM
Gravatar
Total Posts 18439

Re: Admin Extension on Page-Edit

Rather than interogating the MasterPage, the simplest solution might be to just add 1 or 2 more content regions or whatever upper limit you think you need. Whether that tranlates to columns is totally determined by the layout of the MasterPage and the css. I think the number of content regions needs to be a known quantity to keep things simple though lots of pages will only use 1 or 2 of them.

The PageLayout.aspx page just determines which content region the module is placed in, it really has no bearing on how the content regions are laid out even though we currently label them left center and right. Once a module is added to a content region that data (which content region its in) goes in the db so we can't have that content region disappear later if we pick a different skin. Thats why I say the laoyut page needs a known quantity of content regions, it shouldn't be dynamic to whetever happens to be in the layout.Master. There needs to be a contract assuring that layout.master has the expected content regions.

Joe
You must sign in to post in the forums. This thread is closed to new posts.