Project

General

Profile

Actions

Bug #5194

closed

demos are difficult to find

Added by Christopher Brooks over 13 years ago. Updated almost 12 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
general
Target version:
Start date:
09/29/2010
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
5194

Description

Help | Kepler Documentation says:

"All listed demos are in the KeplerData/workflows/module/outreach-2.X.Y/demos/getting-started"

That path name is difficult to find as it is long and there is a
"KeplerData/modules" directory that is confusing.

Also, if I follow the typical pattern of looking at the help file,
opening a demo, then closing the demo and looking at the help file,
I need to retraverse the confusing path hierarchy each time.

To replicate:
1. Help | Kepler Documentation
2. File | Open, then browse through to
KeplerData/workflows/module/outreach-2.X.Y/demos/getting-started"
3. Open the 04-HelloWorld.kar
4. Run the demo and close it.
5. Now, look at the Kepler Documentation page and try to open the next
demo. The result is I have to go through the Open dialog again.

This is not very usable and does not promote actually viewing the demos.
There should be hyperlinks in the text that opens the demos.

Actions #1

Updated by Christopher Brooks about 13 years ago

In Kepler2.2rc3, how do I run the demos?
Help -> Kepler Documentation says:

"Workflow Demonstration Examples
Note that the demos are not included in the default developers build. To download the demos, run:
cd build-area
ant get -Dmodule=outreach"

1) This is not the developer release, this is Kepler-2.2rc3.dmg.
2) There is no build-area

Actions #2

Updated by David Welker about 13 years ago

The second comment is a duplicate of bug 5331. This issue has since been addressed.

Actions #3

Updated by Daniel Crawl almost 12 years ago

I agree that getting the hyperlinks working again for the demos would be good. The difficulty is that the demos listed on the Help->Kepler Documentation page reside in the outreach module whose path in the file system changes based on the module version.

The path to the outreach module's workflows can be accessed via the java property "outreach.workflowdir". One solution is to update ptolemy.actor.gui.HTMLViewer to handle links with java properties. For example, the path could be expressed using the expression language:

<a href="ptexpr:property('outreach.workflowdir') + \"demos/getting-started/04-HelloWorld.xml\"">

To do this, HTMLViewer would use the Ptolemy expression language to parse links beginning with ptexpr. What do you think, Christopher?

Actions #4

Updated by Christopher Brooks almost 12 years ago

I updated ptolemy.actor.gui.HTMLViewer so that if the URL cannot
be found, then it is passed to ptolemy.util.FileUtilities.nameToURL()
that understands things like $CLASSPATH.

So, if you put the user's ~/KeplerData/workflows/module/outreach directory in the classpath and
refer to the urls like
<a href="$CLASSPATH/demos/getting-started/00-StatisticalSummary.xml">Statistical Summary</a>

then the link should work.

We have the classpath, we should use it.

Having the url be able to get a property is a possibility, but using the
classpath is cleaner.

I don't want to have a URL execute arbitrary Ptolemy expression language
code because someone could extend this to support:
<a href="ptexpr:exec("rm veryimportantfile")">Model</a>

Can the outflow/workflow directory be added to the classpath or do you really
want to read the property?

If you want to read the property, then maybe
<a href="property:outreach.workflow/demos/getting-started/04-HelloWorld.xml">Hello World</a>
would be ok.

This would just call ptolemy.util.StringUtilities.getProperty(),
which does not invoke the expression language, but does understand
certain properties and does not return null.

Also, property: is more like about: and other protocol syntaxes.

Comments?

Actions #5

Updated by Daniel Crawl almost 12 years ago

Thanks for updating HTMLViewer, Christopher. The demos were moved from module/resources/ to module/workflows/ since they were not needed on the classpath: http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5034#c3. I discussed this with Derik, and we could not find a strong reason to prevent them from being on the classpath. It will increase Kepler's already long classpath. There also exists the possibility of malicious classes residing in these directories, but that seems unlikely. So, if no objects, I'll update the classpath...

Actions #6

Updated by Daniel Crawl almost 12 years ago

Classpath updated, and demo hyperlinks put back in the help docs.

Actions #7

Updated by Redmine Admin about 11 years ago

Original Bugzilla ID was 5194

Actions

Also available in: Atom PDF