Re: [JBoss-dev] JNuke dev

[Dain Sundstrom]

Who is doing the XDoclet integration? I think it would be a good project for that person.

-dain

On Tuesday, January 14, 2003, at 02:27 PM, Bill Burke wrote:

What I should have said is content developers. Sorry for the snub, but they
do requiring a dumbing down of software.

Bill

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Dain
Sundstrom
Sent: Tuesday, January 14, 2003 2:19 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JNuke dev


I think you are dreaming, if you think you will every recruit php
developers to any java based solution. Ben, remember the Orielly OS
convention? The php guys are perl guys.

-dain

On Tuesday, January 14, 2003, at 01:03 PM, Ben Sabrin wrote:

Are we developing this for the PHP community or the Java community? Or
more important for the JBoss community? To me it seems that it would
depend on who you are targeting for your user base. If you want to
target the PHP users to bring them to JBoss, then Bill could be right.
If we do not care about the PHP community, we go down the JMX way. I
think the PHP community will never want to do anything with JSP. They
believe they have what they need to be successful and will continue to
innovate in their own circle. For most of the PHP community, what they
have built is scalable to their needs.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:jboss-
[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

-------------------------------------------------------
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

-------------------------------------------------------
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