Hi all,
In our commercial CMS application we have a mechanism where we separate
authoring instances (where content authors fill in content) from
publishing instances (where internet surfers hit). Content authors can
validate the content before publishing it to the publishing instances.
This all
Felix Meschberger wrote:
Hi all,
In our commercial CMS application we have a mechanism where we separate
authoring instances (where content authors fill in content) from
publishing instances (where internet surfers hit). Content authors can
validate the content before publishing it to the
Hi,
Alexander Klimetschek schrieb:
On Thu, Dec 10, 2009 at 11:13, Felix Meschberger fmesc...@gmail.com wrote:
(O2) Add support for RunModes
Our CMS system leverages the RunMode service from
contrib/extensions/runmode to detect whether the system is running as an
authoring or a publishing
I don't like this option, because it creates issues:
* copy-paste is always problematic (yes, my option O1 has then
same issues)
If Bertrand's proposal of using multiple runmodes in the folder name
* merging two tree structures creates additional issues with
respect to ordering
Hi,
Carsten Ziegeler schrieb:
Felix Meschberger wrote:
Hi all,
In our commercial CMS application we have a mechanism where we separate
authoring instances (where content authors fill in content) from
publishing instances (where internet surfers hit). Content authors can
validate the
On Thu, Dec 10, 2009 at 12:04, Felix Meschberger fmesc...@gmail.com wrote:
The same merging has to be done for O2. Maybe if we would use approach
O2 with the properties, but allow for additional folders in between
that are not seen as config, we could achieve the same. And the node
name of
Hi,
Alexander Klimetschek schrieb:
On Thu, Dec 10, 2009 at 12:04, Felix Meschberger fmesc...@gmail.com wrote:
The same merging has to be done for O2. Maybe if we would use approach
O2 with the properties, but allow for additional folders in between
that are not seen as config, we could
On Thu, Dec 10, 2009 at 12:27, Felix Meschberger fmesc...@gmail.com wrote:
Alexander Klimetschek schrieb:
I also think that the merging for my proposed case isn't that
difficult: you just walk the tree below /etc/map as it is done now and
apply things for the runmode they are in (defined by
Hi,
Alexander Klimetschek schrieb:
On Thu, Dec 10, 2009 at 12:27, Felix Meschberger fmesc...@gmail.com wrote:
Alexander Klimetschek schrieb:
I also think that the merging for my proposed case isn't that
difficult: you just walk the tree below /etc/map as it is done now and
apply things for
On Thu, Dec 10, 2009 at 14:47, Felix Meschberger fmesc...@gmail.com wrote:
Ehrm, this is exactly, what I am proposing as Option 2 ... (more or less).
Yes, as I pointed out, the only difference are the empty folders, at
the top level, right below /etc/map.
Regards,
Alex
--
Alexander
Rethinking the whole stuff, I'm against adding anything runmode specific
to the resolution module.
If you look at the current run mode support:
- Bundles - nothing has been added to the framework - this is managed
outside by jcr install
- Configs - config admin does not know about run modes -
Hi Carsten
Rethinking the whole thing, I finally come to the same conclusion ...
So, I will go for option (1): make the /etc/map location configurable.
We may still reconsider a modified option (2) in the future. This may be
something like an enablement property which enables (or disables) a
On Thu, Dec 10, 2009 at 4:53 PM, Felix Meschberger fmesc...@gmail.com wrote:
...So, I will go for option (1): make the /etc/map location configurable
Note that it would be good to be able to find the actual value used
easily, for example via a console plugin and/or INFO log messages.
On Thu, Dec 10, 2009 at 16:05, Carsten Ziegeler cziege...@apache.org wrote:
Rethinking the whole stuff, I'm against adding anything runmode specific
to the resolution module.
If you look at the current run mode support:
- Bundles - nothing has been added to the framework - this is managed
On Thu, Dec 10, 2009 at 17:06, Bertrand Delacretaz
bdelacre...@apache.org wrote:
On Thu, Dec 10, 2009 at 4:53 PM, Felix Meschberger fmesc...@gmail.com wrote:
...So, I will go for option (1): make the /etc/map location configurable
Note that it would be good to be able to find the actual
On Thu, Dec 10, 2009 at 5:35 PM, Alexander Klimetschek aklim...@day.com wrote:
On Thu, Dec 10, 2009 at 17:06, Bertrand Delacretaz
bdelacre...@apache.org wrote:
On Thu, Dec 10, 2009 at 4:53 PM, Felix Meschberger fmesc...@gmail.com
wrote:
...So, I will go for option (1): make the /etc/map
Hi,
Bertrand Delacretaz schrieb:
On Thu, Dec 10, 2009 at 4:53 PM, Felix Meschberger fmesc...@gmail.com wrote:
...So, I will go for option (1): make the /etc/map location configurable
Note that it would be good to be able to find the actual value used
easily, for example via a console
here is my take on the exact use case that we have with the runmode
aware /etc/map it is probably seldomly the case that we actually have
different
mappings it is just that hostname get into our way.
in the classic wcm authoring or development environment one would still like
to see urls that are
18 matches
Mail list logo
