Jump to content


Photo

Module: Languages (multi language content management)


  • Please log in to reply
125 replies to this topic

#121 Oliver

Oliver

    Sr. Member

  • Members
  • PipPipPipPip
  • 134 posts
  • 27

  • LocationBasel, Switzerland

Posted 16 December 2011 - 10:19 AM

Your last hint is exactly, what I thought of.
A template var $context made from
Wire::setFuel('context', $pages->get('/contexthome/'));
.
But I think it would be necessary to make $context a extended version of $pages with e.g. a ->switch($contextname) method. The context's meta data would-as already mentioned-be stored in fields of the special template of the context's home pages.

BTW: Is there a way to keep template fields from being deleted?

#122 ryan

ryan

    Reiska

  • Administrators
  • 7,797 posts
  • 6572

  • LocationAtlanta, GA

Posted 16 December 2011 - 11:35 AM

But I think it would be necessary to make $context a extended version of $pages with e.g. a ->switch($contextname) method.


I think that the only methods in $pages where context would matter are find() and get(). Those methods are also present on every Page object and can perform the same function as they do in $pages. Except they only find() or get() pages from their family tree (children, grandchildren, and so on). So the page you call find() or get() on already has a root context to everything below it, at least that's the intention. Whereas, the intention with the $pages API var is that it encompasses all contexts (like jQuery's $() method). As a result, I'm not sure I totally understand the value of changing the $pages context as it seems like it's duplicating something we already provide.

On the other hand, what I think could add value is providing contexts that can go outside the tree. And maybe this is what you were trying to say before and I didn't understand at first. But I understand code better than writing, so imagine this:

<?php
$context = $pages->context("template=basic-page, modified>=$today");

You could provide any selector as the argument to the context() method. The returned $context would be an instance of PagesType that basically provides you with dedicated get() and find() methods that are confined to the context that was provided in the function call. Meaning, any calls to $context->get() or $context->find() already assume the context that was provided when $context was created. Here's an example:

<?php
$news = $pages->context("template=news"); // no pages are loaded from this
$featured = $news->find("featured=1, sort=-date"); // pages are loaded here

While you can already do this (like below), it's not a good idea for big sites for the reason indicated in the code comment:

<?php
$news = $pages->find("template=news"); // ALL news pages loaded from this
$featured = $news->find("featured=1, sort=-date"); // already loaded pages are filtered here

For that reason, I think providing the ability to create new $pages-like API vars that can be confined to any selector-specified context does provide real value in being able to create your own API vars... especially for bigger sites. Is this related to what you were already thinking, or have I gone off on a tangent? :) Here's how I think you'd use it in a multi language situation:

<?php
$languagePages = $pages->context("has_parent=/fr/");

The only thing I can't get past is just that the result of the above would really be no different than just getting the /fr/ page and assigning it to $languagePages:

<?php
$languagePages = $pages->get("/fr/");

What's different is that $languagePages would be a dedicated PagesType instance in the first example, and just a Page in the second example. But how you would use them and the syntax for subsequent get() and find() calls would be identical... so I'm not sure this particular approach has much value when one only needs a family context, like /fr/. The value seems to come from when you need to take the context beyond that (whether with languages or anything else).

The context's meta data would-as already mentioned-be stored in fields of the special template of the context's home pages.


I'm not sure I understand about the context's metadata? Can you give an example of the metadata?

BTW: Is there a way to keep template fields from being deleted?


So long as a field is attached to a template, it can't be deleted. Do you mean: is there a way to prevent a field from being removed from a template? If so, there is: you can give the field a 'permanent' flag:

$field->flags = $field->flags | Field::flagPermanent; 
$field->save();

You can also make a field non-deleteable by giving it a 'system' flag, so that even if it's not used by any templates, it still can't be deleted:

$field->flags = $field->flags | Field::flagSystem;

If you ever need to remove system or permanent flags, it's intentionally cryptic to remove them (applicable only to system or permanent flags). You can't remove them by just changing the flags or PW will throw an exception. Instead, you have to make your intention clear by first giving it an 'system override' flag:

<?php

// removing the system or permanent bits won't work because PW won't allow it 
$field->flags = $field->flags & ~Field::flagSystem; // exception gets thrown here

// but if you first give it an override flag, PW will let you do it
$field->flags = $field->flags | Field::flagSystemOverride; 
// now you can remove the flags
$field->flags = $field->flags & ~Field::flagSystem; 
$field->flags = $field->flags & ~Field::flagPermanent; 
$field->flags = $field->flags & ~Field::flagSystemOverride;

This information about adding/removing system flags applies to templates and pages too. Though pages use the term 'status' rather than 'flags'.


#123 Oliver

Oliver

    Sr. Member

  • Members
  • PipPipPipPip
  • 134 posts
  • 27

  • LocationBasel, Switzerland

Posted 16 December 2011 - 12:04 PM

Thanks once more for the input. You touched on some aspects I still have to think about. Yeah, I guess things will get clearer as soon as I try to put them into code.

With meta information I meant stuff like context specific URL (to allow context selection by domain) or language information (en-US). The point of introducing an additional template var $context besides accessing the context's subpages, would be to provide the contexts information at any time on any subpage. And to easily switch contexts (from mobile. to www. for example). I'll give it a try. Maybe you are right and there won't be a good reason left in the end for having another template var around.

#124 Nico Knoll

Nico Knoll

    The Boss.

  • Members
  • PipPipPipPipPip
  • 809 posts
  • 401

  • LocationBerlin, Germany

Posted 08 April 2012 - 07:46 AM

Is there a new version already? :)

#125 Oliver

Oliver

    Sr. Member

  • Members
  • PipPipPipPip
  • 134 posts
  • 27

  • LocationBasel, Switzerland

Posted 09 April 2012 - 04:15 AM

Hey Nico, after the multi-language features ryan implemented for backend and static template content, I'm still re-thinking the purpose of my module. The goal is to keep the idea of separate page trees. But basically the new module won‘t be about languages but about contexts the content belongs to. Such a context can - but doesn't have to - be a language. Or a mobile version of your site. You'll be able to define rules like url matching or client language detection to define what page tree to use. An API object var will give you the possibility to switch contexts. And it will be working together with PWs native language management.
The page mapping feature will be provided by an additional module extending the context module by the mapping capabilities you know from language module.
As there is still a lot work to do, I can't tell you yet when I'll be able to push a first stable version. Would need some holidays to focus on this one.

#126 Nico Knoll

Nico Knoll

    The Boss.

  • Members
  • PipPipPipPipPip
  • 809 posts
  • 401

  • LocationBerlin, Germany

Posted 09 April 2012 - 08:08 AM

Sounds nice. Please write when it's ready :)




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users