cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stev...@outerthought.org
Subject [WIKI-UPDATE] GT2003Hackathon GT2003HackathonForms GT2003RealBlocks Mat GT2003HackathonCli Mon Oct 6 11:00:10 2003
Date Mon, 06 Oct 2003 09:00:10 GMT
Page: http://wiki.cocoondev.org/Wiki.jsp?page=GT2003Hackathon , version: 96 on Mon Oct  6 08:34:20
2003 by BertrandDelacretaz

+ 
- ! Form Handling (Sylvain? Bruno?)
+ ! [Form Handling|GT2003HackathonForms] (Sylvain)


Page: http://wiki.cocoondev.org/Wiki.jsp?page=GT2003HackathonForms , version: 1 on Mon Oct
 6 08:34:49 2003 by BertrandDelacretaz

New page created:
+ Sylvain's mini-talk at the GT2003 Hackathon.
+ 
+ Raw notes taken collaboratively during the talk.
+ 
+ 
+ 
+ 


Page: http://wiki.cocoondev.org/Wiki.jsp?page=GT2003RealBlocks , version: 2 on Mon Oct  6
08:08:22 2003 by BertrandDelacretaz

+ ! Real Blocks - introduction by Stefano
+ 
+ !! The Naked Cocoon
+ Today Cocoon  is seen as big servlet by users. With Blocks, you would install a basic Cocoon
(core components + minimal 'hello world') and you'd plugin at runtime, the functionality you
need.
+ 
+ !! Blocks vs. WAR files
+ 
+ Blocks could be seen as similar to WAR files, but will do more. The WAR file equivalent
could be a first phase, but applications loaded from WAR files are isolated and cannot communicate
or depend on each other, whereas Blocks are seen as collaborative (yet isolated) components.
+ 
+ * There is no communication between War files, but Blocks can have dependencies and use
each other's services.
+ * Blocks can also inherit and extend the functionality of other Blocks.
+ 
+ !! What are blocks (dry definitions)
+ * Application-level component model for Cocoon
+ * Units of Cocoon functionality, using clean contracts to communicate between the Cocoon
core and Blocks, and also between Blocks themselves.
+ * A block exposes a __sitemap__ and __Avalon Components__ (both optionally)
+ 
+ !! Blocks use cases
+ * Being able to test and rollback installation of new blocks 
+ * Presentation skins: contract between the content model and the skin
+ * Having different, versioned instances of blocks running side-by-side (how does one specify
that in the block 'connection URI'?
+ 
+ !! Challenges
+ * What interfaces does a block expose? Some XML grammar it supposedly requires to act upon?
+ * Tasks of the DeployManager: keeping classloading sane
+ * Classloading: Blocks will need to expose some java classes to the outside, but not all
of their public classes. If a block uses an outside library, for example, the public java
classes of the library should not necessarily be available outside of the Block.
+ 
+ !! Additional notes
+ Block extension:
+ Wrap one block with another.
+ 
+ ! Block Extension: 
+ 
+ I can say this block can have a contractual relationship, at runtime, with another block.
Calls to base block are extended by (intercepted by) the extending block. If the extender
does not handle, it falls back to the original, which can handle it, or pass it back to Cocoon
itself.
+ 
+ ! Block Reuse:
+ 
+ I ask for a PDF block, but there are 3 implementations.
+ The deployer asks, "which one would you like?".
+ I choose one, the deployer goes off to download it, and hooks it up.
+ Another Block asks for PDF.
+ Cocoon 'knows' I am already using it, it can be used by the new Block without duplication.
+ 
+ 
+ How do we describe this behaviour?
+ Not in a way that can be validatable
+ 
+ Use a weak typing (?): using a URI to locate blocks
+ 
+ You can switch blocks at runtime, test, and rollback if required
+ 
+ Will not directly expose public methods of enclosed components
+ 
+ 
+ 
+ !!Remaining issues
+ 
+ * Any use case/functionality missing?
+ 
+ * How to implement this from scratch?
+     * What parts of Cocoon need to be changed?
+     * How do we reduce the amount of code we touch?
+ 
+ * How do we manage over-componentisation from a community standpoint?
+ 
+ * How do we implement security checking, with digital certification?
+ 
+ * How do we implement the blocker deployer tool?
+ 
+ * How do we trace and debub dependencies?
+     (The blcok deployer reports on it's job)
+ 
+ * What are we going to do with JMX? For blocks - and for the Cocoon core. Should be orthogonal
to the design behind blocks.
+ 
+ * Implementing clustering?
+     Block deployer should be able to replicate a snapshot of the running system onto multiple
machines
+ 
+ 
+ 


Page: http://wiki.cocoondev.org/Wiki.jsp?page=Mat , version: 1 on Mon Oct  6 08:40:51 2003
by Mat

New page created:
+ ----
+ 


Page: http://wiki.cocoondev.org/Wiki.jsp?page=GT2003HackathonCli , version: 1 on Mon Oct 
6 08:22:20 2003 by BertrandDelacretaz

New page created:
+ Upayavira's mini-talk at the GT2003 Hackathon.
+ 
+ Raw notes taken collaboratively during the talk.
+ 
+ ! Short intro about what he has been doing so far
+ Almost rewriting the CLI, actually...
+ 
+ ! Questions and remarks
+ 
+ * What about moving the CLI to Forrest?
+ ** CocoonBean needs to stay inside Cocoon
+ ** What would be the benefit of moving away?
+ ** In the end, we're pretty happy with the way it is, especially if Upa is happy with it
+ 
+ * It's kinda lonely out there... :-)
+ 
+ * Issues with Cocoon and the CLI
+ ** Reading from the persistent store is much slower than from the memory store (like 10
times)
+ 
+ * Open issues
+ ** Database access
+ ** Caching of link gatherer information
+ ** Ant task integration
+ ** Usage reports, reporting features
+ ** Command scheduler
+ 
+ 



Mime
View raw message