NB 6.0 Help Meeting 25 April 2007

In the house: Paul Fussell James Branam, JJC, Joe Silber, Ken Ganfield


Technical Questions

Where will help live?

Right now VWP help and NB/Web Apps help mixed with all JEE help in the J2EE module.

VWP DB topics include creating db connections, binding to db within applications.

KG - IDE-level functionality - DB module concerned with creating/adding db connections. We'll keep data binding stuff in with Visual Web, but IDE-level stuff will go in J2EE module. Though the exact location TBD.

Shall we merge help sets or not?

PF - must ensure that if user using VW stuff, then VW help always loaded with it.

Also - how do VW developers get access to the help? JJC - All modules will be in CVS - developers check it out as writers do. Re CSH - We'll map IDs into the app. PF says there are specific Java calls to the help set. JJC - Once help merged, there will be a global change to the map file to make references. PF - must make sure the engineers know where all the info will be living.

JJC - QE shouldn't have trouble getting info.

VW functionality merged into JEE pack, when JEE accessed the help set will open and VW help will be available.

PF - KG, do you have a preference as to where VW topics go. KG - Subdirectories currently sorted by functionality. Within in Web directory, there could be separate VW subdirectory. Some of the stuff in the current VWP help can be put into other area. VW-specific functionality stays in its own corner. KG - I want to know how deep the directory structure goes. If too deep, link errors okay.

PF - As WEB-INF in J2EE is just a directory, not a module, it's possible to put VW directory at the same level. Thinking that spreading VW too far throughout the site, could get problematic.

JB - Asks what functionality will stay in VW module and what's duplicated.

JJC - Design decisions to be made - We will have to split out stuff about Java from core platform technology. The Ruby-only release will have no Java, for example.

AIs: CSH calls, Where to put VW docs in J2EE module. Other things:

JB - Who makes the ultimate decision? JJC - barring any technical blockers, Doc team makes the decision. Run by engineering to resolve technical blockers. PF - Quy and the rest of the team needs a heads-up so they know they're in on the process. JB will inform.

TOC and Index - JB and PF will organize in a way that makes sense. PF - The overlap in topics brings up the question "how do we distinguish VW from Web App development. JJC - more thinking required to get this right. JJC would like to see JB and PF to take over the *whole* web apps section, not just VW. PF - This could be a problem as VW a big enough job. JJC/KG - All the info is there, but needs to be integrated.

PF - In future, can see 2 people taking it on, but for this release, we need one more on this (eg, KG)

JJC - Dave saying to scale back OLH to the point where 2 can handle the whole web app section. We really need to hack away at the help so that 2 can handle it.

Can some users use Helen while others do not?

JJC - no one else but JB/PF on this team have used Helen. Is it possible to open the metadata files and make changes? PF - possible but perhaps unwieldy. JJC - If changes happen outside of Helen, Helen won't react? PF - that's correct - why the Helen Projects file checked into CVS.

PF - will have to coordinate metadata file work with all concerned. Diffs very problematic. CVS not a good tool for this.

JJC - We don't have so much trouble at this end - people work in wildly different parts of the meta files at the same time.

PF - good time to separate out Web App stuff. Will enable large-scale work on the help set. JJC - If CVS used correctly, this shouldn't be a problem. PF - Commit process worrying, but JJC says we generally don't have conflicts. JJC - Reason for 2 to be in the same help set is that there's a lot of linking between sets. PF - didn't realise that. KG - Number of links is large.

JJC - Map file very large before even adding VWP TOC. We need to make sure merge is successful.

KG - Web can be in its own separate module.

JJC - Want to put this stuff on the web; those large links going to be a problem.

PF - we need a link checker. JJC - we have this - we need to build the whole IDE for it to work, but this is not done too often.

JJC - not opposed to Web being its own module. KG - Existing nb web is already pretty large - encompasses struts, web services.

JJC - we need a place where the various frameworks are discussed in depth, but OLH is not that place.

JJC - If we pull out the Web App stuff and integrate with VW, it can be put under Helen - a bit of overhead associated with that but in long run will make JB/PF's work flow easier.

AI - JB - Work with Geertjan to evaluate amount of work it takes to split Web help into its own help set. Come back with recommendation for next week. As you look at topics, have your mental machete out to determine what can be lifted from OLH and perhaps other places such as the wiki. (for example).

PF - One approach is to move task-based help over to web and CSH-like stuff in the help. JJC - let's not deep dive at the moment. Should be done consistently across all packs.

Summary - Evaluate whether to put all web stuff in J2EE or split it out. Either way, we need to look at help IDs.

JB to do feasibility analysis; chat with Quy. PF - Look at whether one can use Helen on topics other folks are editing.

JJC - CVS - making sure stuff isn't overwritten. Chat with Geertjan/Troy about logistics.

KG - Splitting out from J2EE makes sense as there's much that can be done with a web app that doesn't require Enterprise level tools.

Discuss design questions below over email (with Paul, James, JJC, Ken, Gail, Geertjan, Troy and Joe) and meet again in 2 weeks.

A cohesive web tier strategy

how front-and-center do we make visual web apps docs?

how do we resolve difference between doing things visually and coding things manually?

how much visibility do we give to other frameworks?


Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo