Surely the Content app would be a better place to store such URLs though?

Besides as I mentioned earlier, I think the best strategy would be to allow URL 
generation to be overridden either via a service or interface.

Regards
Scott

On 8/12/2012, at 3:39 AM, adrian.c...@sandglass-software.com wrote:

> Yes, the Content application supports localization, but an external Wiki (or 
> some other Help source) might not.
> 
> -Adrian
> 
> Quoting Scott Gray <scott.g...@hotwaxmedia.com>:
> 
>> That would work but isn't the content component supposed to support 
>> localization itself?
>> 
>> In regards to being able to swap out a help implementation, IMO all that is 
>> really required is a service that takes in a webSiteId, view name and locale 
>> which them returns a URL.  In order to swap out the implementation it's then 
>> merely a matter of overriding that service with your own URL provider.
>> 
>> Regards
>> Scott
>> 
>> On 5/12/2012, at 3:33 AM, adrian.c...@sandglass-software.com wrote:
>> 
>>> Scott,
>>> 
>>> I agree with your last paragraph and I have suggested it in the past, but 
>>> there doesn't seem to be much interest in it. There is a much simpler way 
>>> to implement help that addresses all of our concerns:
>>> 
>>> 1. Put Help URLs in the UI label files so they can be localized.
>>> 2. Use the Content component to store and display Help data.
>>> 3. Have each component initialize the database with Help data.
>>> 
>>> OFBiz OOTB could have some Help screens available in the Content component, 
>>> but if a user wanted to use some other method, all they would need to do is 
>>> change the Help URLs in the UI label files (to point to an internal Wiki 
>>> for example).
>>> 
>>> -Adrian
>>> 
>>> Quoting Scott Gray <scott.g...@hotwaxmedia.com>:
>>> 
>>>> I haven't had time yet, I was on a computer-free vacation last week and 
>>>> now have a ton to catch up on.
>>>> 
>>>> I've read the pdf document but it's light on implementation detail so I 
>>>> guess I'll have to dig into the patch at some point.
>>>> 
>>>> Thoughts/questions so far:
>>>> - The build time compilation is a concern IMO, I'd like to see a help 
>>>> system that users can edit as needed with things like business specific 
>>>> information and filling in gaps for custom enhancements that the devs 
>>>> didn't document fully
>>>> - I think I saw somewhere that it is planned to commit the generated help 
>>>> html? Why?  Version control is for source code.
>>>> - How would this approach work in multi-tenanted systems where not all 
>>>> apps are available to all tenants? If help is a complete document I'm not 
>>>> sure how it could be restricted by context?
>>>> 
>>>> I think it's important to make a distinction between the 'prettiness' of 
>>>> the proposed implementation and the underlying design.
>>>> 
>>>> I also think it's unfortunate that we're unable to eat our own dog food 
>>>> and use the content app properly given that documentation is ultimately 
>>>> content embedded within OFBiz.  It's a great use-case for improving the 
>>>> content app really.
>>>> 
>>>> Regards
>>>> Scott
>>>> 
>>>> On 4/12/2012, at 7:58 AM, Olivier Heintz wrote:
>>>> 
>>>>> I have tested the new OFBIz webhelp for the last 3 weeks and migrated
>>>>> some help we already have (for projectmgr)
>>>>> 
>>>>> On a end user perspective, webhelp is clearly an enhancement, because
>>>>> search and glossary (and better presentation) help to find the correct
>>>>> information more quickly.
>>>>> On a help writer perspective, docbook file structure is easier to
>>>>> understand that dataresource - content - contentAssoc - ...
>>>>> 
>>>>> There are still some minors problems, but in each case I have found
>>>>> (with Tom help sometime) how to solve it.
>>>>> 
>>>>> I'm waiting a first release is publish to trunk to send jira with these
>>>>> enhancements.
>>>>> 
>>>>> User Help is one of the software quality criteria and webhelp will help
>>>>> ofbiz community to have better one.
>>>>> Tools is not everything, but it's a good step to motivate the community
>>>>> to contribute in this area.
>>>>> 
>>>>> 
>>>>> Le 28/11/2012 19:22, Jacques Le Roux a écrit :
>>>>>> Bump ?
>>>>>> 
>>>>>> Jacques
>>>>>> 
>>>>>> Jacques Le Roux wrote:
>>>>>>> Yes no problems. Depending on what you are starting from, you will need 
>>>>>>> to add binaries files (from my last patch) or not (Tom's
>>>>>>> zips) but with zips you might get some issues, already blurred in my 
>>>>>>> mind.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> 
>>>>>>> Jacques
>>>>>>> 
>>>>>>> From: "Scott Gray" <scott.g...@hotwaxmedia.com>
>>>>>>>> It's been all of 3 days since I asked you to wait for a thorough 
>>>>>>>> review, has that happened yet or will you just keep asking
>>>>>>>> until no one can be bothered asking you to wait any longer?  Patience 
>>>>>>>> is a virtue Jacques, the project has gone over 10 years
>>>>>>>> without this feature and I don't think a few days/weeks/months will 
>>>>>>>> hurt any, especially considering the next release branch
>>>>>>>> isn't due to be created for quite some time.
>>>>>>>> 
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>> 
>>>>>>>> On 19/11/2012, at 8:41 AM, Jacques Le Roux wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> We (Tom and I) are ready to commit the new help (webhelp - 
>>>>>>>>> OFBIZ-4941) in the content component where all work for us, and will
>>>>>>>>> be completed by Tom as he suggested. There are some trivial Birt 
>>>>>>>>> issues which will dissapear when the process will be
>>>>>>>>> completed, see my last comment.
>>>>>>>>> 
>>>>>>>>> Is it ok to commit as is and to improve later? Mostly we want to move 
>>>>>>>>> webhelp outside of the content component in a new, to
>>>>>>>>> stay OOTB, specialpurpose webehlp component. Or do you want this 
>>>>>>>>> addressed before? Note that if you want this addressed now we
>>>>>>>>> expect a rapid help from those who want that...
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> 
>>>>>>>>> Jacques
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 

Reply via email to