Also, you can't call it JNuke.  You must call it Nukes on Java or something
like that.  JNuke is trademarked.

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bill
> Burke
> Sent: Tuesday, January 14, 2003 1:51 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] JNuke dev
>
>
> The only negative comment I have in using JMX is that the PHP
> community may
> have a tough time switching over to Nukes on JBoss if you have to have a
> package structure like a SAR or a WAR.  I hate to say it, but does it need
> to be "dumbed-down" for the PHP community?  This type of
> community needs to
> be able to edit a JSP and immediately see the change on the webserver.  Is
> it possible to be all JSP based for themes, modules and blocks?  You could
> use a URL fragement and JSP:Include to decide what theme to use.
>
> Just a thought.  Maybe JMX and such is the way to go.  Just want
> to give you
> something to think about.
>
> Bill
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > julien viet
> > Sent: Tuesday, January 14, 2003 11:31 AM
> > To: SourceForge.net
> > Subject: [JBoss-dev] JNuke dev
> >
> >
> > hi folks,
> >
> >  JNuke adventure has started.
> > After analysis of PostNuke I've began the development, still
> early though.
> >
> >  I keep everything that's good in PostNuke and throw all the shit away :
> >
> >  modules, blocks, permissions system, url system and themes.
> >
> >  JMX is used for PostNuke components : themes,
> > modules and blocks are all JMX mbeans. Here are my reasons :
> >
> >  A : general
> >
> >  1.we need a component structure, why not JMX ? after all
> >    another forum say that's lightweight.
> >
> >  2.theses components do not have to scale, i.e the number of modules,
> >    blocks and themes is very small.
> >
> >  B : for modules
> >
> >  1.Ability to deploy/undeploy when application is running.
> >
> >  2.It's easy to deploy additional modules as a separate deployment and
> >    have them register in the same registry.
> >
> >  3.PostNuke is all about invoking module functions.
> >    Url like index.php?module=User&op=register means
> >    that the PN must call the method register on module User.
> >    For me that means that the servlet retrieves the mbean
> >    under the name jnuke:publicmodules:name=User
> >    and invokes the operation register().
> >
> >  4.When a module is installed and configured it plug
> >    block mbeans in the JMX.
> >
> >  C : for blocks, same reasons as above except 3 and 4
> >      as invocation is typed for 3.
> >
> >  D : for themes, same reasons as above except 3 and 4
> >      as invocation is typed for 3.
> >
> >
> >  EJB are used for the model :
> >
> >  UserEJB, GroupEJB, UserPermissionEJB, UserGroupEJB will
> > be CMP 2.0 beans. We'll use local invocations and same trick
> > as in forum to make them faster. Plus more beans.
> >
> >  Each module is made of :
> >
> >  1.ModuleMBean : is the module itself, does not provide
> fucntionnalities,
> >   it's used to manager the PublicModule. Main operations are lifecycle
> >   (initialize, activate, unactivate, uninitialize)
> >
> >  2.PublicModuleMBean : is created when ModuleMBean activates and is
> >    responsible for serving requests. The MBean is dynamic and operations
> >    with no arguments and no returns are served.
> >
> >   It's up to the module to do as he wants : if he wants MVC it can, it
> >   it wants to mix HTML and code, it can. First modules won't be MVC
> >   as they simply don't need.
> >
> >   It's up to the model to have the persistence mecanisms it wants. First
> >   modules will use EJB. With lifecycle operations, each module
> can install
> >   itself, for instance :
> >
> >   a ModuleMBean is plugged :
> >   1.module configuration, setup of variables
> >   2.initialize : module can creates table, deploy EJB, plugs block.
> >   3.activate : module
> >   then go to block admin and creates instances of blocks (if module
> >   use blocks), display them on the page.
> >
> >  Each block is made of :
> >
> >  1.BlockMBean : manages BlockInstanceMBean.
> >  2.BlockInstanceMBean : is a block instance, it contains a title
> > and a position
> >    on web page + 3 operations : display(), edit(), update().
> >    display() : displays the block instance
> >    edit() : used to edit the block in block administration
> >    update() : used to upate the block in block admin
> >
> >  Each them is made of various callbacks that displays HTML on the page.
> >  It has to provide location of files like css, gifs, etc...
> >  THe first them I did is made of a servlet that register to JMX
> >  and the doGet operation serves the files. It's default theme.
> >  To make the thing simpler, it will be possible to make theme with JSP
> >  because I want to keep post nuke spirit.
> >
> >  Ideally, even Module and Blocks could be made as JSP of things
> > like that, that keeps
> >  PHP easy to do spirit.
> >
> >  I did not thought a lot about permissions. In PostNuke, each
> > module is responsible
> >  for checking security. I know that could be done with AOP but I
> > don't know if it's
> >  gonna now, later or never :-)
> >
> >  One problem is the configuration persistence. I don't know how
> > our JMX implementation
> > is far there. But if there is a restart, all config must be
> > re-done. JMX persistence
> > will save us there. Even though it's plain file and not JDBC.
> >
> >  I will check out later (now it's a true mess), but I can say
> what works :
> >  Themes + default theme is done
> >  block
> >  modules and module invocation.
> >  That means that yes, it displays me something that's nice to watch
> >  and I can invoke some operations although it's very early.
> >
> >  So now, I am going back to code because time matters.
> >
> > julien
> >
> > ___________________________________________________________
> > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en frangais !
> > Yahoo! Mail : http://fr.mail.yahoo.com
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> > are you planning your Web Server Security? Click here to get a FREE
> > Thawte SSL guide and find the answers to all your  SSL security issues.
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Take your first step towards giving
> your online business a competitive advantage. Test-drive a Thawte SSL
> certificate - our easy online guide will show you how. Click here to get
> started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development



-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to