To be clear myself, I agree with both of you:
1) no applications dependencies for the help system.
2) have the content component in the framework. Or at least a part of it as it's now? I mean the core part. I think we already discussed about that

Sascha is working on the JCR branch, maybe it could be a way to do the last?

Jacques

From: "David E Jones" <[email protected]>
On Apr 20, 2011, at 5:24 PM, Adrian Crum wrote:

On 4/20/2011 3:28 PM, David E Jones wrote:
On Apr 20, 2011, at 1:18 PM, Jacques Le Roux wrote:

From: "Adrian Crum"<[email protected]>
Also, it might be because the Help link depends on the content component, and the framework is no longer dependent on components
in the applications folder.
Is that true now? I thought there were still some dependencies.

Something that needs serious consideration is a redesign of the help system. From my perspective, having the help system closely
tied to the content component is a bad idea - because many installations might 
not use the content component. In addition,
framework-only installations don't use any of the components in the 
applications folder.
I think we all agree on that, still some work ahead it seems...
I don't know that we all agree on that... in fact isn't the idea backwards? In other words shouldn't we move parts (not all) of the content component to the framework instead of removing dependencies on it?



In the original help system, help text was pulled in from a URL that could be configured. There was no dependency on the content component. I still prefer that approach, because a deployment can point to any source of help.

Sorry, I wasn't clear. I didn't mean to comment on anything related to help, just the idea of removing framework dependencies on the content component versus moving parts of the content component into the framework. I'm in favor of the latter.

-David



Reply via email to