bobharner / componentworld Goto Github PK

This can be easily resolved by changing the checklist onclick @parameter with and onchange @parameter.

Tested and works ok, Will push soon.

Basically, the form submission should be on change event on the "checklist" and the "select" components.

On the Home page, when there is a long list of entries, scrolling down and clicking on an item lower down on the list has no apparent effect -- you have to scroll back up to see the entry detail.

What would be cool is to wrap a component around the entry detail div that uses JavaScript to keep the entry detail in view at all times. Something like http://www.vanvanvans.com/designer (but it would be best if it could be done using Prototype/Scriptaculous so we don't have to add JQuery to the stack).

This could maybe be implemented as a "KeepInView" mixin that could be attached to any component.

ModuleEntry classes are no longer needed, since we have established a hierarchy of "entries" rather than distinct ComponentEntries and ModuleEntries. This code needs to be removed after clearing up the data model & object model.

(After authentication & authorization mechanisms are in place) we need to add the ability for a non-admin person to submit a new entry. Maybe they have to create an account, or maybe they just answer a CAPTCHA prompt, not sure. But once they submit, the new entry should be stored as "disabled" and an e-mail sent to the set of users who have the ability to approve submissions. The e-mail should have a link that takes them right into the app to view the entry, and they can then click the "enabled" checkbox and press the Save button.

It would be nice if the original submitter were recorded as the "owner" of the entry and can subsequently edit that entry without further approval.

As part of all this, any edits to any entries at any time should result in a notification e-mail sent to those same approving users. Maybe this would be part of a larger subscribe-to-change-notifications mechanism that anyone could sign up for.

The "Source Type" checkboxes on the index page don't work yet, and never have.

I'm using the checklist component copied from Tapestry 5.3.

The current problem: for some reason the sourceTypeService field is null within SourceTypeEncoder, as though Tapestry isn't bothering to inject the service when (I think) it should. But this same SourceTypeEncoder works fine on the EditEntry page.

src/main/java/org/apache/tapestry/unicorn/services/AppModule.java in back-to-maven branch refers to CycleBindingFactory but there is no source code for CycleBindingFactory class.

...
import org.apache.tapestry.unicorn.bindings.CycleBindingFactory
...
configuration.add("cycle",new CycleBindingFactory(bindingSource));
...

We need edit forms for the EntryType, SourceType and TapestryVersion tables. Probably simple BeanEditForm instances will be fine.

Currently the app works fine under Jetty, but to deploy to the Apache infrastructure it will need to be runnable under Tomcat. Not sure what changes will be needed (maybe none?).

Ultimately this will probably run as tapestry.zones.apache.org:8180/unicorn (although getting rid of the :8180 would be nice).

Currently we're using Derby in embedded mode, and it is configured to only have a single connection in the db connection pool:

[INFO] access.QueryLogger Created connection pool: jdbc:derby:database/componentSearchDB
Driver class: org.apache.derby.jdbc.EmbeddedDriver
Min. connections in the pool: 1
Max. connections in the pool: 1

I assume that we'll want that number to be a bit higher.

Use Tynamo Security (based on Shiro). Consider whether we can use Tynamo-federatedaccounts so that users (which would be mostly Tapestry committers) can use their existing Google or other Oauth-based accounts for authentication rather than having to create a new user name & password.

Need to add pages for managing users and roles. This ties in with the need to add role-based security (a separate issue).

I'm about half way through renaming the project from "Component Finder" and "Unicorn" to "Component World". The package names need to be changed; also, the database, and other things still need to be renamed.

If we select the "checkall" checkbox than it checks all the checkboxes in the given selector.

But if any of those checkboxes gets unchecked than the "checkall" ckechbox should also be unchecked.

I think this is consistent enough behavior fro the CheckAll component

At the moment the database is stored in github for versioning and safeguarding. However, once this app is running in production, we'll need some way to ensure that the database is reliably backed up and restorable when needed. Currently there are over 300 entries in the database, wouldn't want to lose anything new.