bodington-developers — Mailing list for Bodington developers

Re: [Bodington-developers] spring + i12n

[Matthew B. <mat...@ou...>]

Alistair Young wrote:
> Matthew, what's your feeling on this? Should we keep the template
> resources separate and have mutltiple MessageSources in the config file
> or, as we migrate each template to JSP, migrate it's strings to a global
> bod MessageSource file?

If anyone hasn't looked at the spring stuff I just have one 
messagesource at the moment that is used for both JSP and Java i18n.

I think having a global message source is good as some strings will show 
up in more than one page/class.

I think having one per JSP/class leads to too many files, maybe one per 
resource type (one for questionnaire, one for mcq).

Important thing is how we divide up the namespace for the key values. 
Should we prefix all keys with the resource type and use default for the 
global ones?

> Global file would be easier to send to a translator and would keep the
> config file clean.

If we keep the namespace clean it should be easy to join/split i18n 
files for sending to people.

-- 
  -- Matthew Buckett, VLE Developer
  -- Learning Technologies Group, Oxford University Computing Services
  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/

Re: [Bodington-developers] bod sp + guard

[Selwyn L. <sel...@ph...>]

afaik I2 are not even supporting the standard java SP... that was the 
jist of last advisory we read
i think they have done some work on making the C code easier to compile 
on things other than windows, but i don't want to go there again :(

Alistair Young wrote:

>Just curious. I keep hearing mention of I2 Guard. AFAIK there is no I2
>Guard. Guard is a Guanxi entity that doesn't have a parallel in the I2
>implementation.
>
>Has anyone seen anything to the contrary? Do I2 have a distributed Java SP
>now?
>
>  
>

-- 
Selwyn Lloyd
Phosphorix
tel: 07979240124
irc://irc.ionode.org
channel: #ionode
web: http://www.phosphorix.co.uk 
forum: http://forum.ionetwork.ac.uk

Re: [Bodington-developers] spring

[Alexis O'C. <ale...@ou...>]

Ian Boston wrote:
> 
> First off, don't use JSF.
> Unless you are prepared to buy everyone a top end IDE plugin (or 
> complete IDE) from BEA, IBM, Sun, Oracle or one of the other JSF-JCP 
> members.

Java Studio Creator (from Sun) is free these days. Is it a pile of cr#p?

Alexis

[Bodington-developers] bod sp + guard

[Alistair Y. <ali...@sm...>]

Just curious. I keep hearing mention of I2 Guard. AFAIK there is no I2
Guard. Guard is a Guanxi entity that doesn't have a parallel in the I2
implementation.

Has anyone seen anything to the contrary? Do I2 have a distributed Java S=
P
now?

--=20
Alistair Young
Senior Software Engineer
UHI@Sabhal M=F2r Ostaig
Isle of Skye
Scotland

[Bodington-developers] spring + i12n

[Alistair Y. <ali...@sm...>]

Matthew, what's your feeling on this? Should we keep the template
resources separate and have mutltiple MessageSources in the config file
or, as we migrate each template to JSP, migrate it's strings to a global
bod MessageSource file?

Global file would be easier to send to a translator and would keep the
config file clean.

--=20
Alistair Young
Senior Software Engineer
UHI@Sabhal M=F2r Ostaig
Isle of Skye
Scotland

Re: [Bodington-developers] spring

[Sean M. <se...@sm...>]

Thanks, Ian, for the brain dump.

Interesting to see that we mesh on so much. We ran away from JSF at UHI
some time ago as well.

I will have a look at the sakai mini and perhaps we can come back to you
with some ?s / comments....


s



<quote who=3D"Ian Boston">
> Hi,
> I've been lurking for all of 24 hours, Im not a Bodington expert, but I
> can tell you a bit about Spring-Hibernate-JSF in the Sakai context.
>
> First off, don't use JSF.
> Unless you are prepared to buy everyone a top end IDE plugin (or
> complete IDE) from BEA, IBM, Sun, Oracle or one of the other JSF-JCP
> members.
> Personal experience here is bad. Its really difficult to debug, it has
> horrible semantics (you don't own the URL). I tried to write RWiki with
> JSF (what an idiot!) and gave up when I couldn't do GET's, silly me,
> though I was writing a web application :)
> We've also used JSF for about 4 projects before, loosing developers and
>   giving up. Its what caused Antranig to (go mad and) write RSF.
>
> If you want to write Win32GUI apps in a web environment and not know
> anything about the HTTP or HTML, then JSF or ASP.NET+VS2003 is for you!
>
> Rant over.
>
> Spring =3D=3D Good, but be careful.
> -------------------------------
> Spring is the simplest form is great (same can be said for other IoC's)=
.
> It removes nearly all the factory code and provided you are disciplined
> about completely abstract APIs (putting them in the their own jar) and
> implementing those API's you get real separation of concerns.
> Be careful about the Component Manager. The native Spring Component
> manager is quite good, it has a good structure to it and will not cause
> problems reloading etc. If you want more isolation ( as Sakai did) you
> can write your own Component manager, but be careful not to eliminate
> the reload ability. Having 1M lines of code that require a full Tomcat
> restart when 1 package is changes is not exactly fast development. But
> that just means that you Junit test your components properly, and don't
> have to use the tomcat container as your test environment.
>
> Spring also comes with lots of goodies that can make life easier if you
> don't overuse them. eg Declarative Proxies (transaction, method etc)
> Lazy inits
>
> So I would advocate, use it in is basic way and avoid too many of the
> confusing complex concepts, don't try and replace the ComponentManager
> until you know you absolutely have to.
>
> SpringMVC =3D=3D excellent
> ----------------------
> This is a really nice Controller IMHO. It integrates well with Spring
> and leaves you free to choose your own model and view technologies. Its
> very service oriented and doesn't make any demands on how you interact
> with URL's or HTTP. I think its better than struts, but thats just
> personal.
>
> You *must* use the spring plugin for eclipse, it takes all the pain out
> of writing the application context files.
>
> View technology
> ---------------
> Up to you, I like JSP, as view containers with most of the view code in
> beans, eg 10 line JSP that does basic layout. There are plenty of other
> alternatives. Most of the older ones demand that you extend existing
> classes which can be a pain and tie you in knots. It Antranig is
> listening he will no doubt tell you about RSF which is fast, has zero
> bindings and looks just like html. Tapestry is Ok, but has some binding
> issues, the same can be said for Trails. You might also consider SAX
> based XSLT, provided the output is single stage and fast (ie not huge
> chains as is possible with Cocoon). You might also think carefully abou=
t
>   pre-publishing content to an intermediary stage to keep performance
> right up. (This was the one thing that Coursework from Stanford did
> really well, it wrote its own templates greatly reducing server load)
>
> One thing with JSP,s watch out for the perm space they use, if you have
> lots you will run out, and have to increase it. Also big JSPs are not a=
s
> fast as small JSPs with Beans...  and tags with lots of el lead to big
> call trees, all of which costs.
>
> Hibernate =3D=3D good sometimes, bad others.
> ----------------------------------------
> Be careful with hibernate. If you want to do standard CRUD type
> operations on single records, with some lists, then its great. It also
> great an generating Schemas, provided you check what the schema really
> looks like. This aspect takes all the the pain out managing multiple DB
> targets.
>
> Where it is not so great is the way it interacts with the DB. If you
> want to do anything complex (like an optimized join or a bulk update)
> then you are probably better off using Spring JDBC (which has a proxy t=
o
> make life easy). Some of the reasons are.
>
> 1. Hibernate treats the Object model as just that, as you navigate
> object relationships it will either load entire object trees from the
> db, or lazy load individual objects on demand. Each of these is an
> individual sql statement. Often a single SQL statement gets the answer
> at much lower cost.
> Simple example, delete all objects in a collection, this will generate =
1
> SQL delete per object where a single statement would have done the tric=
k.
>
> Hibernate 3 has a bulk update feature that is supposed to address some
> of this, but it will never beat hand coded SQL92.
>
> 2. On update, these multiple statements generate 1000's of locks in the
> DB. Depending on how locking is implemented you will at some point run
> into deadlock situations, MySQL.InnoDB is more susceptible than Oracle.
> For instance, 10 threads, started at the same time all trying to create
> and update a single record, each with their own GUID will deadlock afte=
r
> about 5 attempts. Thats not much load in real life. Oracle is a bit
> better but you *must* use high inittrans settings on the database block=
s
> (default=3D2, with hibernate ~50). Debugging is a complete  nightmare w=
hen
> it happens.
>
> 3. Object staleness. Dont use pessimistic locking, Use optimistic
> locking and *dont* ever put hibernate objects into session and try and
> reattach them between request cycles, its a nightmare to get right (JSF
> sort of makes you want to try this, another reason not to use JSF).
>
> You *must* use the Hibernate eclipse plugin ( Synchornise?) it takes th=
e
> hard work out of most operations
>
>
> Currently my top architecture stack would be
> --------------------------------------------
> A SOA, no/minimal in session state, no big in memory object models, no
> EJB (:)), Separation of Concerns etc etc etc
> Spring
> Hibernate for Schema
> Spring JDBC and Hibernate (for simple crud ops)
> Spring MVC for the controller
> JSP/SAX-XSLT/RSF for the view.
>
> If you are not already using
> maven
> to build (write your own jelly plugin to make it easy to get up and
> running , maven sakai builds sakai)
> keeps dependencies out of SVN and well defined (precise control over
> versions)
>
> svn for SCM
> as both of these make it much easier for a larger number of developers
> to work concurrently. (Sakai has had about 7K commits from about 50
> developers on about 100 components since 1/1/06)
>
> I think thats my 2p's worth.
> You might look a stealing/borrowing/reusing some of the framework parts
> of Sakai if you are thinking in this area, have a look a mini, which yo=
u
> could strip back further.
>
> https://source.sakaiproject.org/svn/sakai/branches/sakai_mini/
>
> url when your up is
> http://localhost:8080/mercury/
> user: admin, admin
>
> Ian Boston
>
> Matthew Buckett wrote:
>> John Norman wrote:
>>> Would you welcome some of my developers to share what we have learned
>>> from our Sakai work? I can get Ian and Antranig to join the list and
>>> maybe someone from Indiana if you want to thrash out where these
>>> technologies work well and where they don't...
>>
>> Yeah I'd be interested to hear about others experience.
>>
>> Background:
>>
>> At the moment Bodington hands control straight to the template(view)
>> which then calls the business logic and renders the response. Template=
s
>> are like restricted JSPs.
>>
>> I wanted to move to an MVC architecture for the servlet layer as it is
>> one of the weaker areas of Bodington at the moment. Due to bodingtons
>> use of good URLs and very page orientated layout some frameworks didn'=
t
>> get much consideration:
>>
>> 	Tapestry - Bad URLs (better now), component architecture.
>> 	JSF - Bad URLs, component architecture.
>>
>> An obvious candidate was struts as it is very popular (if aging) and a=
s
>> a result most experienced Java developers will know a little about it.=
 I
>> also had used it on a previous project. Although I got it working a
>> little I couldn't manage to get it to work well with Bodingtons tree
>> style URLs without starting to hack at struts itself.
>>
>> Next I looked at SpringMVC which is harder to get started with but muc=
h
>> more flexible. SpringMVC has a reasonable community, acceptable
>> documentation and books. SpringMVC works ok alongside Bodington so tha=
t
>> is what I have stuck with so far.
>>
>> For the presentation I used JSPs (no scriptlets) with Core, Spring and
>> Template taglibs. SpringMVC can work with XSLT, Velocity, Freemarker
>> istead of JSPs for view.
>>
>>
>
>
>
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>


--=20
Sean Mehan
Head of e-Frameworks
Learning and Information Services
UHI

Re: [Bodington-developers] spring

[Ian B. <ia...@ca...>]

Hi,
I've been lurking for all of 24 hours, Im not a Bodington expert, but I 
can tell you a bit about Spring-Hibernate-JSF in the Sakai context.

First off, don't use JSF.
Unless you are prepared to buy everyone a top end IDE plugin (or 
complete IDE) from BEA, IBM, Sun, Oracle or one of the other JSF-JCP 
members.
Personal experience here is bad. Its really difficult to debug, it has 
horrible semantics (you don't own the URL). I tried to write RWiki with 
JSF (what an idiot!) and gave up when I couldn't do GET's, silly me, 
though I was writing a web application :)
We've also used JSF for about 4 projects before, loosing developers and 
  giving up. Its what caused Antranig to (go mad and) write RSF.

If you want to write Win32GUI apps in a web environment and not know 
anything about the HTTP or HTML, then JSF or ASP.NET+VS2003 is for you!

Rant over.

Spring == Good, but be careful.
-------------------------------
Spring is the simplest form is great (same can be said for other IoC's). 
It removes nearly all the factory code and provided you are disciplined 
about completely abstract APIs (putting them in the their own jar) and 
implementing those API's you get real separation of concerns.
Be careful about the Component Manager. The native Spring Component 
manager is quite good, it has a good structure to it and will not cause 
problems reloading etc. If you want more isolation ( as Sakai did) you 
can write your own Component manager, but be careful not to eliminate 
the reload ability. Having 1M lines of code that require a full Tomcat 
restart when 1 package is changes is not exactly fast development. But 
that just means that you Junit test your components properly, and don't 
have to use the tomcat container as your test environment.

Spring also comes with lots of goodies that can make life easier if you 
don't overuse them. eg Declarative Proxies (transaction, method etc) 
Lazy inits

So I would advocate, use it in is basic way and avoid too many of the 
confusing complex concepts, don't try and replace the ComponentManager 
until you know you absolutely have to.

SpringMVC == excellent
----------------------
This is a really nice Controller IMHO. It integrates well with Spring 
and leaves you free to choose your own model and view technologies. Its 
very service oriented and doesn't make any demands on how you interact 
with URL's or HTTP. I think its better than struts, but thats just personal.

You *must* use the spring plugin for eclipse, it takes all the pain out 
of writing the application context files.

View technology
---------------
Up to you, I like JSP, as view containers with most of the view code in 
beans, eg 10 line JSP that does basic layout. There are plenty of other 
alternatives. Most of the older ones demand that you extend existing 
classes which can be a pain and tie you in knots. It Antranig is 
listening he will no doubt tell you about RSF which is fast, has zero 
bindings and looks just like html. Tapestry is Ok, but has some binding 
issues, the same can be said for Trails. You might also consider SAX 
based XSLT, provided the output is single stage and fast (ie not huge 
chains as is possible with Cocoon). You might also think carefully about 
  pre-publishing content to an intermediary stage to keep performance 
right up. (This was the one thing that Coursework from Stanford did 
really well, it wrote its own templates greatly reducing server load)

One thing with JSP,s watch out for the perm space they use, if you have 
lots you will run out, and have to increase it. Also big JSPs are not as 
fast as small JSPs with Beans...  and tags with lots of el lead to big 
call trees, all of which costs.

Hibernate == good sometimes, bad others.
----------------------------------------
Be careful with hibernate. If you want to do standard CRUD type 
operations on single records, with some lists, then its great. It also 
great an generating Schemas, provided you check what the schema really 
looks like. This aspect takes all the the pain out managing multiple DB 
targets.

Where it is not so great is the way it interacts with the DB. If you 
want to do anything complex (like an optimized join or a bulk update) 
then you are probably better off using Spring JDBC (which has a proxy to 
make life easy). Some of the reasons are.

1. Hibernate treats the Object model as just that, as you navigate 
object relationships it will either load entire object trees from the 
db, or lazy load individual objects on demand. Each of these is an 
individual sql statement. Often a single SQL statement gets the answer 
at much lower cost.
Simple example, delete all objects in a collection, this will generate 1 
SQL delete per object where a single statement would have done the trick.

Hibernate 3 has a bulk update feature that is supposed to address some 
of this, but it will never beat hand coded SQL92.

2. On update, these multiple statements generate 1000's of locks in the 
DB. Depending on how locking is implemented you will at some point run 
into deadlock situations, MySQL.InnoDB is more susceptible than Oracle. 
For instance, 10 threads, started at the same time all trying to create 
and update a single record, each with their own GUID will deadlock after 
about 5 attempts. Thats not much load in real life. Oracle is a bit 
better but you *must* use high inittrans settings on the database blocks 
(default=2, with hibernate ~50). Debugging is a complete  nightmare when 
it happens.

3. Object staleness. Dont use pessimistic locking, Use optimistic 
locking and *dont* ever put hibernate objects into session and try and 
reattach them between request cycles, its a nightmare to get right (JSF 
sort of makes you want to try this, another reason not to use JSF).

You *must* use the Hibernate eclipse plugin ( Synchornise?) it takes the 
hard work out of most operations


Currently my top architecture stack would be
--------------------------------------------
A SOA, no/minimal in session state, no big in memory object models, no 
EJB (:)), Separation of Concerns etc etc etc
Spring
Hibernate for Schema
Spring JDBC and Hibernate (for simple crud ops)
Spring MVC for the controller
JSP/SAX-XSLT/RSF for the view.

If you are not already using
maven
to build (write your own jelly plugin to make it easy to get up and 
running , maven sakai builds sakai)
keeps dependencies out of SVN and well defined (precise control over 
versions)

svn for SCM
as both of these make it much easier for a larger number of developers 
to work concurrently. (Sakai has had about 7K commits from about 50 
developers on about 100 components since 1/1/06)

I think thats my 2p's worth.
You might look a stealing/borrowing/reusing some of the framework parts 
of Sakai if you are thinking in this area, have a look a mini, which you 
could strip back further.

https://source.sakaiproject.org/svn/sakai/branches/sakai_mini/

url when your up is
http://localhost:8080/mercury/
user: admin, admin

Ian Boston

Matthew Buckett wrote:
> John Norman wrote:
>> Would you welcome some of my developers to share what we have learned  
>> from our Sakai work? I can get Ian and Antranig to join the list and  
>> maybe someone from Indiana if you want to thrash out where these  
>> technologies work well and where they don't...
> 
> Yeah I'd be interested to hear about others experience.
> 
> Background:
> 
> At the moment Bodington hands control straight to the template(view) 
> which then calls the business logic and renders the response. Templates 
> are like restricted JSPs.
> 
> I wanted to move to an MVC architecture for the servlet layer as it is 
> one of the weaker areas of Bodington at the moment. Due to bodingtons 
> use of good URLs and very page orientated layout some frameworks didn't 
> get much consideration:
> 
> 	Tapestry - Bad URLs (better now), component architecture.
> 	JSF - Bad URLs, component architecture.
> 
> An obvious candidate was struts as it is very popular (if aging) and as 
> a result most experienced Java developers will know a little about it. I 
> also had used it on a previous project. Although I got it working a 
> little I couldn't manage to get it to work well with Bodingtons tree 
> style URLs without starting to hack at struts itself.
> 
> Next I looked at SpringMVC which is harder to get started with but much 
> more flexible. SpringMVC has a reasonable community, acceptable 
> documentation and books. SpringMVC works ok alongside Bodington so that 
> is what I have stuck with so far.
> 
> For the presentation I used JSPs (no scriptlets) with Core, Spring and 
> Template taglibs. SpringMVC can work with XSLT, Velocity, Freemarker 
> istead of JSPs for view.
> 
> 

Re: [Bodington-developers] spring

[Matthew B. <mat...@ou...>]

John Norman wrote:
> Would you welcome some of my developers to share what we have learned  
> from our Sakai work? I can get Ian and Antranig to join the list and  
> maybe someone from Indiana if you want to thrash out where these  
> technologies work well and where they don't...

Yeah I'd be interested to hear about others experience.

Background:

At the moment Bodington hands control straight to the template(view) 
which then calls the business logic and renders the response. Templates 
are like restricted JSPs.

I wanted to move to an MVC architecture for the servlet layer as it is 
one of the weaker areas of Bodington at the moment. Due to bodingtons 
use of good URLs and very page orientated layout some frameworks didn't 
get much consideration:

	Tapestry - Bad URLs (better now), component architecture.
	JSF - Bad URLs, component architecture.

An obvious candidate was struts as it is very popular (if aging) and as 
a result most experienced Java developers will know a little about it. I 
also had used it on a previous project. Although I got it working a 
little I couldn't manage to get it to work well with Bodingtons tree 
style URLs without starting to hack at struts itself.

Next I looked at SpringMVC which is harder to get started with but much 
more flexible. SpringMVC has a reasonable community, acceptable 
documentation and books. SpringMVC works ok alongside Bodington so that 
is what I have stuck with so far.

For the presentation I used JSPs (no scriptlets) with Core, Spring and 
Template taglibs. SpringMVC can work with XSLT, Velocity, Freemarker 
istead of JSPs for view.


-- 
  -- Matthew Buckett, VLE Developer
  -- Learning Technologies Group, Oxford University Computing Services
  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/

Re: [Bodington-developers] spring

[John N. <jo...@ca...>]

Would you welcome some of my developers to share what we have learned  
from our Sakai work? I can get Ian and Antranig to join the list and  
maybe someone from Indiana if you want to thrash out where these  
technologies work well and where they don't...

John

On 6 Jun 2006, at 14:37, Matthew Buckett wrote:

> Alistair Young wrote:
>> I have a chat tool to do - should I do it in the "normal" way or  
>> wait and
>> do it in the spring way?
>
> My current state of play is:
>
> Currently working on user import code (a week more work).
> The I need to finish off some MyWebLearn work (implement quotas and  
> tidy up)
> The we have do our testing and bug fixes (1st August - 15thAugust).
>
> After that things are a little quieter and I will document the
> SpringMVC/JSP setup I currently have.
>
> Currenlty my work is on a branch of the WebLearn tree which needs
> merging onto WebLearn HEAD as well.
>
> If you need this in a rush then don't wait.
>
> You are welcome to have a look at how I have been doing this and
> feedback/fix. I snapshot of my current workspace is at:
>
> http://users.ox.ac.uk/~buckett/weblearn-spring.tar.bz2
>
> The MyWebLean code uses SpringMVC/JSPs.
>
> -- 
>   -- Matthew Buckett, VLE Developer
>   -- Learning Technologies Group, Oxford University Computing Services
>   -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/
>
>
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers

Re: [Bodington-developers] hibernate ~ spring ~ common core

[Selwyn L. <sel...@ph...>]

hi Alistair

yeah LDAP is just an example in terms of 'common' vocab for things we 
could share across integrated apps

I think the first point I'm trying to raise is perhaps OSS communities 
in e-learning might agree one common layer to bind
applications together.

Our business case is for quickly resuable tools within a service 
application, such as a PLE, VLE or other learner centric ecclectic service.

Meaning you can quickly integrate our tools into your application and 
vice versa.

So while I'm not 100% sure what OID's are...
wrt to unique ID's we use GUIDS to pair between non related apps and 
distinct insitutions so we store collections of instituion ID plus 
applications user unique ID pairs against a interoperability GUID....

the idea is to to integrate more tools within another application here 
though and less identities across services...
so yes with this model, our collective 'future tetra based tools' share 
a common person id method,
or as 'de niro' put it so aptly in meet the fockers our tools are in 
[the circle of trust] :)

Sel

Alistair Young wrote:

>Could you expand on what common core means Selwyn? Perhaps I'm way off on
>a tangent here but you mentioned LDAP as a core schema. The federated
>services world started along this route (eduPerson) but seem to be
>migrating away from it and leaving schema design to application
>developers, using the OID model.
>
>Do you mean, e.g. Tetra can see "user_id" in bod_db and know it's the same
>as "userid" in sakai_db? That would be a semantic nightmare unless OIDs
>were used. We could define a Tetra OID space.
>
>Plug in a new application with it's own db, have it provide an OID layer
>for it and hey presto, "Tetra" can AAA users across applications:
>
>- User logs in to Sakai
>- User clicks on link to login to Bod questionnare (say)
>- Bod is shibbed so "Tetra" kicks in
>- "Tetra" says to Sakai - give me OIDs 1.45.5.3 and 9.4.21.4
>- Something makes a decision based on the values of those attributes
>defined by those OIDs.
>
>Sounding like a XACML layer in there too!
>
>I only mention it as the concepts sound a wee bit the same.
>
>  
>

-- 
Selwyn Lloyd
Phosphorix
tel: 07979240124
irc://irc.ionode.org
channel: #ionode
web: http://www.phosphorix.co.uk 
forum: http://forum.ionetwork.ac.uk

Re: [Bodington-developers] hibernate ~ spring ~ common core

[Alistair Y. <ali...@sm...>]

Could you expand on what common core means Selwyn? Perhaps I'm way off on
a tangent here but you mentioned LDAP as a core schema. The federated
services world started along this route (eduPerson) but seem to be
migrating away from it and leaving schema design to application
developers, using the OID model.

Do you mean, e.g. Tetra can see "user_id" in bod_db and know it's the sam=
e
as "userid" in sakai_db? That would be a semantic nightmare unless OIDs
were used. We could define a Tetra OID space.

Plug in a new application with it's own db, have it provide an OID layer
for it and hey presto, "Tetra" can AAA users across applications:

- User logs in to Sakai
- User clicks on link to login to Bod questionnare (say)
- Bod is shibbed so "Tetra" kicks in
- "Tetra" says to Sakai - give me OIDs 1.45.5.3 and 9.4.21.4
- Something makes a decision based on the values of those attributes
defined by those OIDs.

Sounding like a XACML layer in there too!

I only mention it as the concepts sound a wee bit the same.

--=20
Alistair Young
Senior Software Engineer
UHI@Sabhal M=F2r Ostaig
Isle of Skye
Scotland

> sorry, the question was... did the topic get aired?
>
> still I'll try and deal with your concern about innovation and explain
> our perspective a little more with some kind of illustration in text :)
>
>
> *innovation
>
> putting a lid on innovation would be the last thing on our mind [please
> be assured of that]
> on the contrary a common core data structure provides a license to
> innovate sensibly.
> regards application innovation you can have as many application
> databases as you like, common is just that 'common'.
>
> *common core
>
> the proposal is so that a concept such as Tetra has a core on which to
> build,
>
> in this integrated model
>
> user application [presentation layer]
> components & services layer
> application data layer
> common data layer
>
> or in a little more detail
>
>
>      my integrated portal thingy me bob [bod 2]
>                               |
>      bod tetra   |  sakai tetra  |  ioportal tetra
>         |                     |                        |
>      bod_db      sakai_db         ioportal_db
>         |                     |                        |
>                               |
>                     common core
>
> *schema
> If I was going to propose a common core to begin with then it might be
> based on LDAP / Enterprise hybrid but I'm not proposing the schema, jus=
t
> asking if the topic was aired.
> perhaps the LDAP schema is to generic for us and we need to extend that
> to cope with other common considerations in e-learning.
> but common core all about calling a spade a spade and reuseability.
>
> Cheers
>
> Sel
>
>
>
>
>
>
>
> Peter Crowther wrote:
>
>>>From: Selwyn Lloyd
>>>did the idea of a common schema for an abstraction layer get aired?
>>>
>>>we figured that a common core gives us more ways to integrate
>>>different
>>>developemnt models, i.e. spring, struts, portlets, web services and
>>>other models can sit side by side if we had a common storage model
>>>for a core e-learning schema
>>>
>>>
>>
>>Intuitively this feels even harder to standardise than common
>>interchange formats, and feels like standardisation at the wrong level
>>to boot.  People expect interchange formats to be lossy, and there can
>>be more than one of them for a given area.  By contrast, multiple
>>storage models are beggars to integrate.
>>
>>What would you propose to standardise?  How would you propose to let
>>developers innovate in the presence of a common core (or is one of the
>>goals to put a lid on unwanted innovation)?  Would you expect a
>>table-based or hierarchical storage model?
>>
>>		- Peter
>>
>>
>>_______________________________________________
>>Bodington-developers mailing list
>>Bod...@li...
>>https://lists.sourceforge.net/lists/listinfo/bodington-developers
>>
>>
>>
>>
>
> --
> Selwyn Lloyd
> Phosphorix
> tel: 07979240124
> irc://irc.ionode.org
> channel: #ionode
> web: http://www.phosphorix.co.uk
> forum: http://forum.ionetwork.ac.uk
>
>
>
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>

Re: [Bodington-developers] hibernate ~ spring ~ common core

[Selwyn L. <sel...@ph...>]

sorry, the question was... did the topic get aired?

still I'll try and deal with your concern about innovation and explain 
our perspective a little more with some kind of illustration in text :)


*innovation

putting a lid on innovation would be the last thing on our mind [please 
be assured of that]
on the contrary a common core data structure provides a license to 
innovate sensibly.
regards application innovation you can have as many application 
databases as you like, common is just that 'common'.

*common core

the proposal is so that a concept such as Tetra has a core on which to 
build,

in this integrated model

user application [presentation layer]
components & services layer
application data layer
common data layer

or in a little more detail


     my integrated portal thingy me bob [bod 2]
                              |
     bod tetra   |  sakai tetra  |  ioportal tetra
        |                     |                        |
     bod_db      sakai_db         ioportal_db
        |                     |                        |
                              |
                    common core

*schema
If I was going to propose a common core to begin with then it might be 
based on LDAP / Enterprise hybrid but I'm not proposing the schema, just 
asking if the topic was aired.
perhaps the LDAP schema is to generic for us and we need to extend that 
to cope with other common considerations in e-learning.
but common core all about calling a spade a spade and reuseability.

Cheers

Sel







Peter Crowther wrote:

>>From: Selwyn Lloyd
>>did the idea of a common schema for an abstraction layer get aired?
>>
>>we figured that a common core gives us more ways to integrate 
>>different 
>>developemnt models, i.e. spring, struts, portlets, web services and 
>>other models can sit side by side if we had a common storage model
>>for a core e-learning schema
>>    
>>
>
>Intuitively this feels even harder to standardise than common
>interchange formats, and feels like standardisation at the wrong level
>to boot.  People expect interchange formats to be lossy, and there can
>be more than one of them for a given area.  By contrast, multiple
>storage models are beggars to integrate.
>
>What would you propose to standardise?  How would you propose to let
>developers innovate in the presence of a common core (or is one of the
>goals to put a lid on unwanted innovation)?  Would you expect a
>table-based or hierarchical storage model?
>
>		- Peter
>
>
>_______________________________________________
>Bodington-developers mailing list
>Bod...@li...
>https://lists.sourceforge.net/lists/listinfo/bodington-developers
>
>
>  
>

-- 
Selwyn Lloyd
Phosphorix
tel: 07979240124
irc://irc.ionode.org
channel: #ionode
web: http://www.phosphorix.co.uk 
forum: http://forum.ionetwork.ac.uk

Re: [Bodington-developers] hibernate ~ spring ~ common core

[Matthew B. <mat...@ou...>]

Selwyn Lloyd wrote:
> wrt spring, is hibernate part of spring or does it have its own 
> abstraction layer?

Hibertnate is a standalone Object Relational Mapping library. Spring 
provides some wrappers around it so you don't have to tie your higher 
levels (business logic) to things like its exceptions. Spring also 
provides wrappers for JDO, Toplink, etc.

It also provides abstraction of transactions from JTA/JDBC.

I'm not using any of this in the SpringMVC/JSP development.

-- 
  -- Matthew Buckett, VLE Developer
  -- Learning Technologies Group, Oxford University Computing Services
  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/

Re: [Bodington-developers] hibernate ~ spring ~ common core

[Peter C. <Pet...@me...>]

> From: Selwyn Lloyd
> did the idea of a common schema for an abstraction layer get aired?
>=20
> we figured that a common core gives us more ways to integrate=20
> different=20
> developemnt models, i.e. spring, struts, portlets, web services and=20
> other models can sit side by side if we had a common storage model
> for a core e-learning schema

Intuitively this feels even harder to standardise than common
interchange formats, and feels like standardisation at the wrong level
to boot.  People expect interchange formats to be lossy, and there can
be more than one of them for a given area.  By contrast, multiple
storage models are beggars to integrate.

What would you propose to standardise?  How would you propose to let
developers innovate in the presence of a common core (or is one of the
goals to put a lid on unwanted innovation)?  Would you expect a
table-based or hierarchical storage model?

		- Peter

Re: [Bodington-developers] spring

[Matthew B. <mat...@ou...>]

Alistair Young wrote:
> I have a chat tool to do - should I do it in the "normal" way or wait and
> do it in the spring way?

My current state of play is:

Currently working on user import code (a week more work).
The I need to finish off some MyWebLearn work (implement quotas and tidy up)
The we have do our testing and bug fixes (1st August - 15thAugust).

After that things are a little quieter and I will document the 
SpringMVC/JSP setup I currently have.

Currenlty my work is on a branch of the WebLearn tree which needs 
merging onto WebLearn HEAD as well.

If you need this in a rush then don't wait.

You are welcome to have a look at how I have been doing this and 
feedback/fix. I snapshot of my current workspace is at:

http://users.ox.ac.uk/~buckett/weblearn-spring.tar.bz2

The MyWebLean code uses SpringMVC/JSPs.

-- 
  -- Matthew Buckett, VLE Developer
  -- Learning Technologies Group, Oxford University Computing Services
  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/

[Bodington-developers] hibernate ~ spring ~ common core

[Selwyn L. <sel...@ph...>]

wrt spring, is hibernate part of spring or does it have its own 
abstraction layer?

did the idea of a common schema for an abstraction layer get aired?

we figured that a common core gives us more ways to integrate different 
developemnt models, i.e. spring, struts, portlets, web services and 
other models can sit side by side if we had a common storage model
for a core e-learning schema

cheers




-- 
Selwyn Lloyd
Phosphorix
tel: 07979240124
irc://irc.ionode.org
channel: #ionode
web: http://www.phosphorix.co.uk 
forum: http://bsd1.phosphorix.co.uk

Re: [Bodington-developers] spring

[Adam M. <ada...@co...>]

Depends on your timescales I guess, Mattie's jsp/spring 'how to' wont be
available until end of august (I think), however, he could (possibly)
verbally tell you over the phone.=20

It would certainly be a 'GOOD THING' if you could try things out at this
early stage, both of you together should be able to crack this nit.

adam

| -----Original Message-----
| From: bod...@li...
| [mailto:bod...@li...] On Behalf =
Of
| Alistair Young
| Sent: 06 June 2006 13:58
| To: bod...@li...
| Subject: [Bodington-developers] spring
|=20
| I have a chat tool to do - should I do it in the "normal" way or wait =
and
| do it in the spring way?
|=20
| --
| Alistair Young
| Senior Software Engineer
| UHI@Sabhal M=F2r Ostaig
| Isle of Skye
| Scotland
|=20
|=20
|=20
|=20
| _______________________________________________
| Bodington-developers mailing list
| Bod...@li...
| https://lists.sourceforge.net/lists/listinfo/bodington-developers

Re: [Bodington-developers] spring

[Naomi M. <na...@sm...>]

spring is sprung!  I think you should wait and spring it.

On 6 Jun 2006, at 13:58, Alistair Young wrote:

> I have a chat tool to do - should I do it in the "normal" way or =20
> wait and
> do it in the spring way?
>
> --=20
> Alistair Young
> Senior Software Engineer
> UHI@Sabhal M=F2r Ostaig
> Isle of Skye
> Scotland
>
>
>
>
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers

[Bodington-developers] spring

[Alistair Y. <ali...@sm...>]

I have a chat tool to do - should I do it in the "normal" way or wait and
do it in the spring way?

--=20
Alistair Young
Senior Software Engineer
UHI@Sabhal M=F2r Ostaig
Isle of Skye
Scotland

Re: [Bodington-developers] meeting notes

[Colin T. <col...@ou...>]

Sean Mehan wrote:
> need a login and a passwd to edit.
> 
> seanskye, please!
>  or you could shibb it!-)
> 
> 
> <quote who="Adam Marshall">
> 
>>Now online at:
>>
>>	http://bodington.org/wiki/
>>
>>Please add your own guff into the meeting notes page AND (more
>>importantly)
>>add text to the release notes page.
>>
>>Brian - do you have a picture, it'd be good for the website.
>>
>>adam
>>
>>
>>
>>_______________________________________________
>>Bodington-developers mailing list
>>Bod...@li...
>>https://lists.sourceforge.net/lists/listinfo/bodington-developers
>>
> 
> 
> 


-- 
____________________________________
Colin Tatham
VLE Team
Oxford University Computing Services

http://www.oucs.ox.ac.uk/ltg/vle/
http://bodington.org

Re: [Bodington-developers] meeting notes

[Sean M. <se...@sm...>]

need a login and a passwd to edit.

seanskye, please!
 or you could shibb it!-)


<quote who=3D"Adam Marshall">
> Now online at:
>
> 	http://bodington.org/wiki/
>
> Please add your own guff into the meeting notes page AND (more
> importantly)
> add text to the release notes page.
>
> Brian - do you have a picture, it'd be good for the website.
>
> adam
>
>
>
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>


--=20
Sean Mehan
Head of e-Frameworks
Learning and Information Services
UHI

Re: [Bodington-developers] meeting notes

[Sean M. <se...@sm...>]

need a login and a passwd to edit.

seanskye, please!



<quote who=3D"Adam Marshall">
> Now online at:
>
> 	http://bodington.org/wiki/
>
> Please add your own guff into the meeting notes page AND (more
> importantly)
> add text to the release notes page.
>
> Brian - do you have a picture, it'd be good for the website.
>
> adam
>
>
>
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>


--=20
Sean Mehan
Head of e-Frameworks
Learning and Information Services
UHI

Re: [Bodington-developers] meeting notes

[Peter C. <Pet...@me...>]

> From: Adam Marshall
> 	http://bodington.org/wiki/
>=20
> Please add your own guff into the meeting notes page

... Can I have an account please?  Username 'Ozzard', for preference, to
match the SF identity.

		- Peter

[Bodington-developers] meeting

[Adam M. <ada...@co...>]

http://bodington.org/wiki/index.php?title=DevMeet1Jun06

now with photos

Re: [Bodington-developers] JSPs vs Bod templates

[Sean M. <se...@sm...>]

I think we did, with the proof of concept and showing of the cards from
Matthew first!-)

s


<quote who=3D"Adam Marshall">
> Did we formally agree that all new developments with bod should use JSP=
 /
> Spring? (With the proviso that Matthew must write a developers guide
> first).
>
> If we did agree this then we really should all bite the bullet and not =
shy
> away!
>
> adam
>
>
>
>
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>


--=20
Sean Mehan
Head of e-Frameworks
Learning and Information Services
UHI