Re: multi-workspace support in script resolution
Hi Justin, thanks a lot for your swift response. I think the subject of this thread is slightly misleading... it really should be scripts should be resolved from the same workspace as resources. Which is essentially the summary of SLING-1446. ahhh ok, that definitely makes more sense... They are not for separating things out, like user A has a workspace and user B has a workspace, they are also not for separation by type. I have to stop you there. user-specific workspaces seem like a perfectly legitimiate use of workspaces IF those users are editing the same content tree. Agreed. Which would make in turn use of merge() update() and clone() ;) Imagine four workspaces: 1) user1 2) user2 3) trunk 4) publish A node is created in user1 at /content/index, then clone() is called in trunk [i.e. clone(user1, /content/index, /content/index, false)]. The node is then cloned into user2 [i.e. clone(trunk, /content/index, /content/index, false)]. User2 makes some changes in their workspace, saves, and then updates the node in trunk [node.update(user2)]. Finally, the node is clone from trunk to publish and is user-facing. The key point I've understood about workspaces and their appropriate use is that workspaces are supposed to represent the same content tree. Having private working copies doesn't seem to violate this. Absolutely. I agree with you. Maybe I should clarify that in the wiki... I was mostly referring to a usecase of multi-tenancy that people sometime mistake as a good usecase for workspaces. By the by, something to consider for JCR 3 is that clone/update/merge all operate from the perspective of the target workspace (i.e. the workspace being cloned into, updated, merged). For promotion workflows, I believe corresponding methods called from the source workspace/session would be more natural, similar to how git push works. Hmm... Good point. Maybe even JCR 2.1. I think the issue is that to make modification in a workspace other than the one that you have a session to is something that we lack some machinery for... thanks for the follow-up. regards, david
Re: Runmode support for /etc/map configuration
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 as close as the ones that we have in production but of course we would not like the links to be rewritten to go fully qualified urls with a domain name... so generally i think the /etc/map tree will look very similar from runmode to runmode but in one every other runmode other than production i would probably either want to put the domain name somewhere in to the url that indicates to the user that this would be a link that would go to http://www.example.org/test in production. so probably could be resolved to something like http://mydev/www.example.org/test . keep in mind though that usually there are only going to be very few link where that would actually make a difference since this assumes that an application has cross domain links under management within one sling instance. to be perfectly honest, for our commercial solution, i think we can do perfectly without the runmode aware /etc/map regards, david On Thu, Dec 10, 2009 at 9:05 PM, Felix Meschberger fmesc...@gmail.com wrote: 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 plugin and/or INFO log messages. Yes, makes sense. Regards Felix -Bertrand -- David Nuescheler Chief Technology Officer mailto: david.nuesche...@day.com web: http://www.day.com/ http://dev.day.com twitter: @daysoftware
Re: script resolution by hostname ?
hi markus, it was brought to my attention, that i forgot to mention the sharing of content amongst websites as a use case so i would like to clarify the below statement a little bit more in detail... if you assume that you have separate content trees but would like to share the applications or the security (the users) it is perfectly feasible to run things off of one sling instance. if you want to share content (in the broader sense) amongst sites, including website content, apps, config, users or anything else stored in the repository, you possibly want to use one single sling instance. as a rule of thumb i would say that the more you share, the higher the chances of a shared sling instance. isolation makes sense in the hosting usecase where you have different customers that (must) share nothing. regards, david
Re: script resolution by hostname ?
hi markus,
in my experience running different websites (for the lack of a better
term) in an environment is really a matter of isolation/separation
between the instances.
if you assume that you have separate content trees but would like to
share the applications or the security (the users) it is perfectly
feasible to run things off of one sling instance.
if you want to reach a greater isolation like running multi websites that
are completely separate i usually recommend to run things off of
different sling instances. even different jvm instances.
especially if you would like to have a degree of isolation where
a programming mistake in one website (let's say a while(true){})
does not impact the other websites i would definitely advocate separate
jvms.
really the cost of running a separate sling instance is a little bit of
disk-space and a few dozens of megabytes of heap.
regards,
david
2009/8/26 Alexander Klimetschek aklim...@day.com:
On Wed, Aug 26, 2009 at 5:58 PM, Markus Pallopa...@dig.de wrote:
The use case is each site has custom content which should not reflect to
others.
And there is a news provider prvoviding news which both sites should use and
modification on these news should reflect on all sites immediatly.
So probably we could have three content trees domain1, domain2, shared.
Right, that's how it is typical.
If we have two or three different content trees in the same repository, how
to configure resource search path that the scripts will be found for the
corresponding content tree (site layout) ? The nodes have same
sling:resourceType.
Well, they should have a different resource type then. Or, in cases
where it makes sense, you can make the behaviour of scripts depending
on the domain.
But in general, in a CMS/webapp scenario, you want to reuse your
scripts (or components) with different content, not the other way
around. Changing content is easier than developing new scripts and/or
duplicating scripts.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetsc...@day.com
--
David Nuescheler
Chief Technology Officer
mailto: david.nuesche...@day.com
web: http://www.day.com/ http://dev.day.com
twitter: @daysoftware
