[aplaws - Developing on APLAWS+] ccm.home and r1919

[Aplaws - Dev mailing list]

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=7404141
By: pboy

Hi Terry,

I suppose your patch will break a lot of modifications I made to the java code.

The rationale of milestone (1) is that all references to files, resources and
anything else in APLAWS is strictly made relative to document root rsp. the
web application context

All modifications / configurations regarding the servlet container and where
to install APLAWS (in which context) are the responsibility of the container
/ the container administrator / the container's webapp installation tool. Nothing
at all that APLAWS should care about.

In some situations we need the full file system path to a file or resource (esp.
during installation / initial configuration and while using the test machinery
I suppose), and we need the path to the APLAWS web context. That is ccm.home
in the logik of milestone (1).

Currently ccm.home is fixed ${app.server.webapp.dir}/ROOT. As soon as I've finished
the work on the URL resource: protocol (I suppose I will provide a patch today
in the evening) I will start to make APLAWS installable in any arbitrary directory,
specified in project.xml webapp tag or during installation time. This involves
a massive rewriting of xsl files and a lot of work in web.xml and the dispatcher
magic and may take some time.

So ccm.home will become:  ${app.server.webapp.dir}/${ccm:project.webapp}

See milestone (1) and related tickets for details.

Well, I suppose I should start to write a new developer guide as soon as
possible.

In which situations do we need ccm.home pointing to the servlet containers home
dir?


Peter


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=368401

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
Aplaws-devel mailing list
Aplaws-devel@...
https://lists.sourceforge.net/lists/listinfo/aplaws-devel

[Aplaws - Dev mailing list]

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=7404150
By: terry_permeance

ant start worked

ant load-bundle put the configuration under
webapps/ROOT/webapps/ROOT/WEB-INF/conf

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=368401

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
Aplaws-devel mailing list
Aplaws-devel@...
https://lists.sourceforge.net/lists/listinfo/aplaws-devel

[Aplaws - Dev mailing list]

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=7404219
By: pboy


'Hm, seems to be another example where my svn didn't work. I will have a look
into it.

But can we agree about the underlying rationale?



Peter



______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=368401

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
Aplaws-devel mailing list
Aplaws-devel@...
https://lists.sourceforge.net/lists/listinfo/aplaws-devel

[Aplaws - Dev mailing list]

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=7404347
By: bprucha

> I will start to make APLAWS installable in any arbitrary directory, specified
in project.xml webapp tag or during installation time. This involves a massive
rewriting of xsl files and a lot of work in web.xml and the dispatcher magic
and may take some time.

Peter, I have already done work to get APLAWS to run under a context other than
root.  It does not require a massive rewrite of xsl files.  The xsl files get
loaded through the templating system which will look for the xsl files under
the context defined with the web.context (from memory) registry configuration
setting.

I can help you with the changes that do need to be made.  Their aren't that
many as far as getting it to run is concerned.  I'm going to be away for several
days but can provide a path when I get back.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=368401

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
Aplaws-devel mailing list
Aplaws-devel@...
https://lists.sourceforge.net/lists/listinfo/aplaws-devel

[Aplaws - Dev mailing list]

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=7407641
By: pboy

Hi Brett,

it would be very very helpful if you could contribute your experiences and provide
a patch. Your patch regarding ResourceParameter  was the "breakthrough" to get
the problem resolved.

Regarding rewriting of xsl files: I had (rather) a short look into some files
and found a huge amount of references to other xsl files (includes) which contain
the ROOT directory as a fix part of the path. So I suppose we have to have a
look into every file (or let grep do that) to check for absolute path
specifications.

My idea is: if we have to look into nearly every xsl file, we should use that
occasion to thorougly clean up the web directory structure as well. Currently
it's really a mess. Files a spread all over the directory, functional identical
files are stored at different locations, some files are doubled at different
locations, theme files are mixed with logic files, etc.

It is nearly impossible to maintain such a code structure. But in order to improve
APLAWS's usability, we must lay emphasis on themes / easy themability. That
involves a lot of maintenance work.

A possible structure of the web dir might be:

- themes
- themes/internal (assembles all the files of the current build-in "theme")
- themes/mandalay (the new, modularized and easy configurable theme developed
in Bremen)
- themes/public (maintained by ccm-themesmanager aka ccm-ldn-themes)
- themes/devel  (maintained by ccm-themesmanager aka ccm-ldn-themes)
- themes/default  (maintained by ccm-themesmanager aka ccm-ldn-themes)
- themes/aplaws (current default theme)

- scriptlib
- scriptlib/xinha
- scriptlib/fckeditor
- scriptlib/other Javascript

- templates (jsp per module)

- WEB-INF

I suppose you concentrated on the web.xml file and the dispatcher configuration.
So we could split the work.


Peter



______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=368401

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
Aplaws-devel mailing list
Aplaws-devel@...
https://lists.sourceforge.net/lists/listinfo/aplaws-devel

[Aplaws - Dev mailing list]

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=7416886
By: bprucha

Peter,

You must be refering to packages other than ccm-core or ccm-cms.  I do not use
the other packages so don't know about how they include other XML templates.

In the XML templates for ccm-core and ccm-cms I had to replace the
<a href="/somefile"> urls with <a href="{$context-prefix}/somefile">.  For APLAWS
applications that I developed myself that run outside of the APLAWS context
I modified com.arsdigita.templating.SimpleURIResolver.  This class is used by
the TransformerFactory that the XSL Templates use to resolve the location of
the XML template files.  I used "/@ccm_context@" as a special string in the
include which gets replaced by the APLWAS context in SimpleURIResolver.  You
can follow a similar method to resolve the other XML includes to suit your needs
for the other apps, no need to edit the XML template files.

I don't have time now but some time next week I should be able to get a patch
file together which allows the core APLAWS to run under a context other than
ROOT.


Thanks,

Brett

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=368401

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Aplaws-devel mailing list
Aplaws-devel@...
https://lists.sourceforge.net/lists/listinfo/aplaws-devel

[Aplaws - Dev mailing list]

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=7424607
By: pboy

Brett,

|  You must be refering to packages other than ccm-core or ccm-cms.
|  I do not use the other packages so don't know about how they
|  include other XML templates.

Yes indeed, mostly those packages which used to install into their own web context
as ccm-userpreferences, or ccm-ldn-themes as an example. They contain include
statements like "../../../../ROOT/static/.......", because they directly use
resources from modules installed into ROOT (and vice versa) - very strange
design.

I startet to check all the xml files and to remove all absolute adressing.

I studied your hints about SimpleURIResolver - and I'm wondering a little bit
about the design decisions behind it. I think XML templates, which render a
xml information to html, are very private to the module which maintains that
information. It should never be used by any other module directly, and even
more so by another web application (if there is a need to access that information,
an jee service or a content type as proxy site or xmlfeed should be used). So
I would expect a real "Simple" way would be to resolve any xsl template as a
resource relative to it's own context.

Things are even worse with the parameter waf.web.server, which must contain
the correct url including the port, otherwise c.ad.templating.XSLTemplate can
not find the resource (fails at line 100). I suppose, an application user should
not be forced to take the system administrators cnfiguration philosophy into
account. Why not fetch it from the we applications context?

Even more worse with c.ad.caching.CacheServlet. It reads the host's name and
port from a persistent database table (we have no maintenance tool as to my
knowledge). So every time the system administrator modifies e.g. the port, we
either produce a bunch of log errors or we have to manually edit the database.

Do you have a solution / idea for these latter two issue as well? I'm eager
to study your patch.


Peter



______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=368401

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
Aplaws-devel mailing list
Aplaws-devel@...
https://lists.sourceforge.net/lists/listinfo/aplaws-devel

[Aplaws - Dev mailing list]

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=7470171
By: bprucha

> I think XML templates, which render a xml information to html, are very private
> to the module which maintains that information. It should never be used by
any
> other module directly, and even more so by another web application

The problem is that the presentation layer depends upon Bebop XSLT in ccm-core.
Each module should be able to run in its own context but it also needs to access
the core XSLT components of Bebop.  I don't think each individual module should
have it's own copy of the core resources.

> if there is a need to access that information, an jee service or a content
type
> as proxy site or xmlfeed should be used

The stylesheet-paths.txt file describes where to look for these resources and
by default points to the resource-resolver servlet through an absolute URL.
The templating system translates this into a call to resolve the resource from
the local context to optimize resource lookup.

> Why not fetch it from the we applications context?

It is fetched from the applications context.  Using the ::webapps:: variable
in stylesheet-paths.txt the resource can be lookup up in multiple contexts.

> Even more worse with c.ad.caching.CacheServlet. It reads the host's name and
> port from a persistent database table

I've never had to change these values so haven't run into this problem.  It's
used to support clustering I suppose.  I haven't ever looking into it since
I've never changed the host name or used clustering.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=368401

------------------------------------------------------------------------------
_______________________________________________
Aplaws-devel mailing list
Aplaws-devel@...
https://lists.sourceforge.net/lists/listinfo/aplaws-devel

[Aplaws - Dev mailing list]

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=7470649
By: pboy

Hi Brett,


>  The problem is that the presentation layer depends upon Bebop XSLT in ccm-core.
>  Each module should be able to run in its own context but it also needs to
access the core XSLT
>  components of Bebop. I don't think each individual module should have it's
own copy of the core resources.

Is it really true, that each module should be able to run in its own context?
I asked on the forum and tried hard to find a reason for it.

E.g. why should ccm-ldn-theme run in its own context? By design (i.e. the xml
include mechanism) it provides services for just one web application, that one
that is running in ROOT. Nothing else. It used to store all the themes in its
own context, but a theme is very specific to a web application, no one wants
to mix themes between several web applications.

Of course, several web applications might use the services, the module ccm-ldn-themes
provides. Therefore, the jar files might be / should be stored in the containers
shared lib directory so it can be used by any web application. But each web
application will store the themes in its ówn context (xsl but also logo, images
and other private or specific things the webapp might not be willing to share).
And it will store the theme of the admin interface in its own context and might
whish to modify or redesign it.

As to my knowledge version 5 of APLAWS  was a JEE application, were all modules
were installed into one context (ccm). Do you know, WHY that had been changed?
I suppose I never understood this design decision.


Currently, the development system had been changed so that all modules are installed
into one context which is specified in project.xml. If there is a requirement,
that a module should run in its own context, I have to adjust the
build-template.xsl.

Just another topic: If each module is dependent from resources in core, I suppose
it is an example of (very) strong coupling. So it should not divided into different
modules (at least according to theory :-)  )


>   It is fetched from the applications context. Using the ::webapps:: variable
in stylesheet-paths.txt the resource
>   can be lookup up in multiple contexts

That works very well for the core dispatcher, but does not work inside of xml
files (include directive, a mechansim which is widely used in APLAWS). Therefore,
if we decide that every module must be able to run in its own context, we have
to find a solution.

Therefore the question is: Is it essential for your usage of APLAWS / CCM that
each module is able to run in its own context,
or is it sufficient that jar files are stored in a shared directory
or can we determine specific circumstances for the requirement to run in ist
own context (some sort of special kind or types of modules) for which we can
develope a solution for the include directive in xsl files (of make them
unneccessary).


Peter



______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=368401

------------------------------------------------------------------------------
_______________________________________________
Aplaws-devel mailing list
Aplaws-devel@...
https://lists.sourceforge.net/lists/listinfo/aplaws-devel

[Aplaws - Dev mailing list]

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=7470657
By: pboy

Brett,

> > It is fetched from the applications context. Using the ::webapps:: variable
in stylesheet-paths.txt the resource
> > can be lookup up in multiple contexts
 
>  That works very well for the core dispatcher, but does not work inside of
xml files (include directive, a mechansim
>  which is widely used in APLAWS). Therefore, if we decide that every module
must be able to run in its own context,
>  we have to find a solution.

Sorry, I forgot that you already developed a solution for this part.

Peter


 



______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=368401

------------------------------------------------------------------------------
_______________________________________________
Aplaws-devel mailing list
Aplaws-devel@...
https://lists.sourceforge.net/lists/listinfo/aplaws-devel

[Aplaws - Dev mailing list]

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=7475944
By: bprucha

> Is it really true, that each module should be able to run in its own context?

I don't see modules necessarily as being an extension to the existing functionality.
A module can provide completely new and independent functionality.  Developers
should be able to use the core as a lower level framework for their own applications.
This is what I use the code for.  I tap into the user/group/permission functionality
and dispatcher and templating mechanism to create multiple themable instances
of my applications.  Beyond that, the software I've developed stands on its
own.  Having each module in it's own context also makes it truly modular.  You
don't have to merge the moduals web.xml in with the core web.xml.  This also
allows you to undeploy/redeploy individual moduals without having
to undeploy/redeploy the entire system.  Those are the main benefits I see in
having modules in their own context.  I don't think each module has to be in
its own context but when a module provides new application services that simply
rely on the core for lower level API it's nice of have that capability.

> a theme is very specific to a web application, no one wants to mix themes
between several web applications.

Why not?  In an enterprise environment you want all of you applications to have
the same look and feel.

> As to my knowledge version 5 of APLAWS was a JEE application, were all modules
were installed into one
> context (ccm). Do you know, WHY that had been changed? I suppose I never understood
this design decision.

I'm not sure why.  The code used the c.a.sitenode.SiteNodeDispatcher to locate
the package dispatcher to handle the request.  That was deprecated in favor
of the c.a.web.DispatcherServlet which tries to forward the request to a servlet
defined in c.a.web.Application.  The new dispatcher mechanism is more flexible
and allows the application to reside in a different context.  My guess is that
it makes the moduals more plug and play.

> Just another topic: If each module is dependent from resources in core, I
suppose it is an example of
> (very) strong coupling. So it should not divided into different modules (at
least according to theory :-) )

I see core as being a lower level web framework that should be in a shared jar.
I think much of whats in their can/should be replaced with other competing
technologies that are maintained as independent projects.  What should stay
are the things that make APLAWS+ truly unique like the way it handles
users/groups/permissions and dispatches modules in a way that facilitates multiple
instances of an application.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=368401

------------------------------------------------------------------------------
_______________________________________________
Aplaws-devel mailing list
Aplaws-devel@...
https://lists.sourceforge.net/lists/listinfo/aplaws-devel