Re: cvs commit: jakarta-jetspeed/webapp/WEB-INF/templates/jsp/layouts/html/de default.jsp

[ingo schuster <in...@web.de>]

At 19:29 03/08/01, David Sean Taylor wrote:
> >  Added:       webapp/WEB-INF/templates/jsp/layouts/html/de default.jsp
>etc...
>
>Looks like you are going forward with storing JSPs in the WEB-INF directory,
>despite the fact that the group has not agreed upon it.

The group has not agreed upon it yet, correct. And as long as there is no 
agreement, I'll stick with the way of doing things that is used up to now. 
Moving a few template files is not big of a deal anyway.

>Im not sure what to say about that, except that I believe all votes are
>considered equal at Apache.

Right, all votes are equal. However: nobody asked to vote up to now, I 
think the +1s are to be regarded as personal opinions, not votes. It 
wouldn't be a good idea to vote about things before they are fully 
discussed. Apart from that, I counted two +1s, one -1 from me - want to 
say: We need more discussion.

>I also see that you are writing your own implementation of a Templating
>Service, and not using Turbine's.
>Have you discussed with them our needs for language specific templates?

Yes I have, and understood that it's best to write a own service. Turbine's 
services are not taboo, on the contrary they are meant to be the default 
implementation (and will probably do for 95% of all users), but if you want 
to do something special, that is not important to a large community of 
users, it's better to write your own version of a service than having 
exotic functionality in the default implementation. (It's a pity I couldn't 
subclass the TurbineTemplateService as I overwrote only one method)
Having said this, I agree, that my modifications are probably useful for 
more turbine users and I will post to the turbine list and ask if they are 
interrested. However, since we are always a few weeks behind turbine, I 
think it is acceptable to implement the functionality first in an own 
jetspeed service, try it out and remove it once the changes have gone into 
the tdk. That's what I did with the JspTemplatingService for example.

>Do you remember seeing a discussion with Santiago last week, wrt to a common
>fallback algorithm?
>I was under the impression that we agreed upon having a common fallback
>algorithm shared by the profiler and templating services.

Yes, of course, it was me that started this discussion. I'm +1 on a common 
fallback mechanism ("ResourceLocatingService"?). Again, I can't see a 
problem with my commits - I'm happy to remove the code, as soon as there is 
a common fallback mechanism. Just for the start, to win new functionality, 
I checked my changes in (there not _that_ big, actually minor modifications 
in 4 classes...). I regard open source development more as evolutionary, 
i.e. with lot of refactoring (call it rapid prototyping or XP, whatever). 
The core of the project should become and stay stable, it should grow, but 
new code that brings new functions may be unstable for some time.

Still, I can see your point. Jetspeed has been a chaotic project regarding 
development so far: Everybody modifies code everywhere, and we are not 
always using a proper proposal-vote-implementation approach. I think this 
ok so far, the project core is still under heavy refactoring, but once it 
get's more stable (and once the number of active committers grows), we need 
to use rules and processes that ensure that all important modifications are 
agreed upon by the majority of developers, that not two committers work on 
the same item, etc. I could imagine gatekeepers for certain parts of the 
code - people that now about all activities regarding "their" code and are 
to be asked before changes in order to asure that all work that is done 
fits together.

>Im more than willing to modify the profiler service algorithm to use
>directories, or to even use your algorithm.
>The *point* is I'd like to see us all work together, and not have two (or
>more)implementations of the same service, and different directory layouts.

See above. My implementation is just a sample, so to say a working 
specification of what I'd like to have. I'm absolutely +1 for refactoring, 
I'm not emotionally attached to my code ;-). I just think it is not a bad 
idea to share ideas through code, even if this code will be refactored in a 
more general approach soon.

>Perhaps with the new layout impl., there won't be a need for a
>directory-based fallback algorithm on profiles.
>Im not entirely sure right now, since I haven't seen the default layout
>implementation yet from Raphael.
>I am guessing that it will store psml in configuration files....but will
>these configuration files be per user/media type/language???

Perhaps not language, but per user/media type seems sensible. And even 
though a serious installation would store the profiles in a datastore, I 
think a directory-based fallback mechanism still makes sense for our 
default development jetspeed.

Regarding a "ResourceLocatingService", I thought of an mechanism that takes 
a base path and a file path and tries to locate the file given in the file 
path, similar to what the template service does. E.g.:

locateResource("/WEB-INF/templates/jsp", "/html/en/xy.jsp"); would look for
1. [..]/WEB-INF/templates/jsp/html/en/xy.jsp
2. [..]/WEB-INF/templates/jsp/html/xy.jsp
3. [..]/WEB-INF/templates/jsp/xy.jsp
and return file path of the first match,

locateResource("/work/jetspeed/psml", "/groupZ/userXY/html/page1.psml"); 
would look for
1. [..]/work/jetspeed/psml/groupZ/userXY/html/page1.psml"
2. [..]/work/jetspeed/psml/groupZ/userXY/page1.psml"
3. [..]/work/jetspeed/psml/groupZ/page1.psml"
and return file path of the first match

Optionally, the result of the lookup would be cached in for performance 
reason, but there must be a way to delete certain entries or the whole 
cache explicitly (e.g. after an update: new files or removal of a file). 
Nice to have would be a timeout value for cached entries.

A service of this kind could be used from the profiler as well as from the 
template service, perhaps turbine is even interested in it.

ingo.


>- david
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

Re: subclass the TurbineTemplateService

[Jon Stevens <jo...@latchkey.com>]

on 3/12/01 1:16 AM, "ingo schuster" <in...@web.de> wrote:

> At 20:16 03/09/01, Jon Stevens wrote:
>> on 3/9/01 2:25 AM, "ingo schuster" <in...@web.de> wrote:
>> 
>>> (It's a pity I couldn't
>>> subclass the TurbineTemplateService as I overwrote only one method)
>> 
>> Uh. Why not?
> 
> Because there are too many "privates" in the code. As soon as I have
> finished some other work, I'll ask on the turbine list to change it to
> "protecteds" and then have another try.
> 
> ingo
> 
>> -jon

Ingo,

Submit a patch to make them public or protected or whatever you need! It
isn't that hard. Geeez...

-jon


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

Re: subclass the TurbineTemplateService

[ingo schuster <in...@web.de>]

At 20:16 03/09/01, Jon Stevens wrote:
>on 3/9/01 2:25 AM, "ingo schuster" <in...@web.de> wrote:
>
> > (It's a pity I couldn't
> > subclass the TurbineTemplateService as I overwrote only one method)
>
>Uh. Why not?

Because there are too many "privates" in the code. As soon as I have 
finished some other work, I'll ask on the turbine list to change it to 
"protecteds" and then have another try.

ingo

>-jon


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

subclass the TurbineTemplateService

[Jon Stevens <jo...@latchkey.com>]

on 3/9/01 2:25 AM, "ingo schuster" <in...@web.de> wrote:

> (It's a pity I couldn't
> subclass the TurbineTemplateService as I overwrote only one method)

Uh. Why not?

-jon

-- 
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

RE: cvs commit: jakarta-jetspeed/webapp/WEB-INF/templates/jsp/layouts/html/de default.jsp

[David Sean Taylor <da...@bluesunrise.com>]

Ingo Schuster wrote:
> The group has not agreed upon it yet, correct. And as long as
> there is no
> agreement, I'll stick with the way of doing things that is
> used up to now.
> Moving a few template files is not big of a deal anyway.
>

Alright, then it is clear that the location of the templates is undecided.
I suggest that we vote on template location, along with all the other
resource locations under WEB-INF that was discussed previously.
I am still not ready to vote. I have open cases with Weblogic and ATG that I
am waiting on. They both seem close to being resolved...
I'd like to wait until I officially hear back from them before voting.

For now, templates will remain under WEB-INF.

> Yes, of course, it was me that started this discussion. I'm
> +1 on a common
> fallback mechanism ("ResourceLocatingService"?). Again, I can't see a
> problem with my commits - I'm happy to remove the code, as
> soon as there is
> a common fallback mechanism. Just for the start, to win new
> functionality,
> I checked my changes in (there not _that_ big, actually minor
> modifications
> in 4 classes...). I regard open source development more as
> evolutionary,
> i.e. with lot of refactoring (call it rapid prototyping or
> XP, whatever).
> The core of the project should become and stay stable, it
> should grow, but
> new code that brings new functions may be unstable for some time.
>
> Still, I can see your point. Jetspeed has been a chaotic
> project regarding
> development so far: Everybody modifies code everywhere, and
> we are not
> always using a proper proposal-vote-implementation approach.

Yes, this is true. I believe that new services and features should be first
submitted as informal proposals to the group.
Everyone can then comment and hopefully find some new insight to the
problem.
I find this valuable, although its true that a good implementation is more
effective that any discussion.
The code speaks for itself, and it can easily be refactored for small proof
of concepts.
Perhaps a combination of both is best. It doesn't really matter which comes
first, the proof of concept or the proposal.

> I think this
> ok so far, the project core is still under heavy refactoring,
> but once it
> get's more stable (and once the number of active committers
> grows), we need
> to use rules and processes that ensure that all important
> modifications are
> agreed upon by the majority of developers, that not two
> committers work on
> the same item, etc. I could imagine gatekeepers for certain
> parts of the
> code - people that now about all activities regarding "their"
> code and are
> to be asked before changes in order to asure that all work
> that is done
> fits together.

These are great ideas (Im a little short of time right now, sorry if I dont
comment more, but I am taking notes )

> See above. My implementation is just a sample, so to say a working
> specification of what I'd like to have. I'm absolutely +1 for
> refactoring,
> I'm not emotionally attached to my code ;-). I just think it

No, of course we aren't emotional. We are professionals ... :-)
We are just committed to doing quality work, and that is a good thing.

> is not a bad
> idea to share ideas through code, even if this code will be
> refactored in a
> more general approach soon.

I agree. I wish I were sharing more ideas through coding.
As of late, I seem to be communicating soley through all these damn emails
:(

>
> >Perhaps with the new layout impl., there won't be a need for a
> >directory-based fallback algorithm on profiles.
> >Im not entirely sure right now, since I haven't seen the
> default layout
> >implementation yet from Raphael.
> >I am guessing that it will store psml in configuration
> files....but will
> >these configuration files be per user/media type/language???
>
> Perhaps not language, but per user/media type seems sensible.
> And even
> though a serious installation would store the profiles in a
> datastore, I
> think a directory-based fallback mechanism still makes sense for our
> default development jetspeed.
>
> Regarding a "ResourceLocatingService", I thought of an
> mechanism that takes
> a base path and a file path and tries to locate the file
> given in the file
> path, similar to what the template service does. E.g.:
>
> locateResource("/WEB-INF/templates/jsp", "/html/en/xy.jsp");
> would look for
> 1. [..]/WEB-INF/templates/jsp/html/en/xy.jsp
> 2. [..]/WEB-INF/templates/jsp/html/xy.jsp
> 3. [..]/WEB-INF/templates/jsp/xy.jsp
> and return file path of the first match,
>
> locateResource("/work/jetspeed/psml",
> "/groupZ/userXY/html/page1.psml");
> would look for
> 1. [..]/work/jetspeed/psml/groupZ/userXY/html/page1.psml"
> 2. [..]/work/jetspeed/psml/groupZ/userXY/page1.psml"
> 3. [..]/work/jetspeed/psml/groupZ/page1.psml"
> and return file path of the first match
>

This looks like a nice abstraction,
although perhaps a 'default' basepath could be configured, with a variation
locateResource(path)

I see you are 'grouping' users under groups.
Doesn't this limit a user to being in only one group?
In the profiler proposal, there are different directory trees for groups and
users.
Access to the group resources by users is controlled by turbine acls.

> Optionally, the result of the lookup would be cached in for
> performance
> reason, but there must be a way to delete certain entries or
> the whole
> cache explicitly (e.g. after an update: new files or removal
> of a file).
> Nice to have would be a timeout value for cached entries.
>

WRT cache, I've given this some thought in the profiler.
There are some cache-control interfaces, but no implementation yet.

> A service of this kind could be used from the profiler as
> well as from the
> template service, perhaps turbine is even interested in it.
>

Okay. I think we agree on a common ResourceLocator service.
We can look at the profiler and the template service and begin refactoring
there.
Great, Im glad we had this discussion :)

-- david



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org