From: "Scott Gray" <[email protected]> >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,
The Webhelp as it is now can't achieve fast build time compilation, the xslt transformation eats much of it. >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 This can perhaps be achieved by following the Webhelp documentation and maybe some support. What kind of interfacve would you envision? > - I think I saw somewhere that it is planned to commit the generated help > html? Why? Version control is for source code. The idea is to have a ready help OOTB, as it exists currently with simple Docbook on which is based Webhelp. Also we could chain the ant task which build the new help (like we have load-demo for instance) but then we would not have the Webhelp OOTB, for instance in the demo server, which would be a pity. Tom proposed to complete what is already done once it will be committed. This is a significant part of work and I'd not like his proposition to help to be rejected without really good reasons. For now it's a pain to handle from the committer side because the new help system (not the generated part, which is easy to do, just run ant webhelp.all) is not integrated and you have to pick files in archives and moves them in folders > - 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? Do we really need to worry about that for a 1st phase? What do you envision that will differ OOTB? > > I think it's important to make a distinction between the 'prettiness' of the > proposed implementation and the underlying design. If someone has good ideas for the underlying design then I will be all ears of course. But this should not prevent us to block the work done. We can always improve later as we already suggested for a new specific webhelp component. Thinking more about it, why not in the framework instead of specialpurpose as already suggested? Is it not a crucial/basic part of any system to have an embedded way of building helps? Of course this question concerns only the gnerating part not the generated one. > 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. That's another story, if ever someone comes with something better or improving based on that, then yay! But I fear this will not happen in a near/mid term future, why wait? Let's be realistic, we can have a better looking and much improved help, why stop it? Jacques > > 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" <[email protected]> >>>>> 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 >> > >
