Versions Compared

Old Version 86

changes.mady.by.user Apereo Infrastructure

Saved on

compared with

New Version 87

changes.mady.by.user Apereo Infrastructure

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

[08:26:34 CDT(-0500)] <EricDalquist> getting closer and closer with the new pipeline
[08:26:44 CDT(-0500)] <EricDalquist> getting through the serializer differences now
[08:27:15 CDT(-0500)] <EricDalquist> apparently the custom SAX->XHTML serializer uPortal currently has does a bunch of random things that aren't really 'okay' XML wise
[08:27:33 CDT(-0500)] <EricDalquist> so tweaking the XSL to not depend on them
[09:51:59 CDT(-0500)] <athena> that's awesome
[09:52:22 CDT(-0500)] <athena> sounds like a lot of progress (smile)
[09:52:23 CDT(-0500)] <EricDalquist> do we want the xhtml xmlns declaration?
[09:52:27 CDT(-0500)] <EricDalquist> it isn't there right now
[09:52:38 CDT(-0500)] <EricDalquist> but now that we're using a real serializer it is passed through
[09:52:40 CDT(-0500)] <athena> i suppose we should probably have one?
[09:52:49 CDT(-0500)] <EricDalquist> well I'll leave it in
[09:53:06 CDT(-0500)] <EricDalquist> I wonder if I should leave the xmlns:dlm namespace declaration in too
[09:53:45 CDT(-0500)] <athena> i was thinking about taking a look at the user account portlet stuff next
[09:54:02 CDT(-0500)] <EricDalquist> user account management?
[09:54:09 CDT(-0500)] <athena> this ticket: https://issues.jasig.org/browse/UP-2593
[09:54:17 CDT(-0500)] <athena> since the old password channel is missing now
[09:54:22 CDT(-0500)] <EricDalquist> ah yeah
[09:54:36 CDT(-0500)] <athena> are we ready to replace up_person_dir with JPA?
[09:54:40 CDT(-0500)] <EricDalquist> yes
[09:54:42 CDT(-0500)] <athena> ok
[09:54:44 CDT(-0500)] <EricDalquist> I was just typing that
[09:54:52 CDT(-0500)] <athena> it seemed like we should be able to do that w/o affecting users, layouts, etc.
[09:54:56 CDT(-0500)] <athena> and i see you already have a ticket for that
[09:54:56 CDT(-0500)] <EricDalquist> potentially UP_USER too if it seems sane to do so
[09:55:00 CDT(-0500)] <EricDalquist> yeah
[09:55:21 CDT(-0500)] <EricDalquist> but I think we could do up_person_dir by itself too
[09:55:26 CDT(-0500)] <athena> i know profiles and layouts have a lot of references to the up_users tables - i don't know if that would cause problems or not
[09:55:41 CDT(-0500)] <EricDalquist> ah yeah
[09:55:50 CDT(-0500)] <EricDalquist> maybe we leave that to the next version
[09:55:53 CDT(-0500)] <athena> i'm guessing for the account edit stuff we'll need to have a way to determine if a user is a local user or not
[09:56:00 CDT(-0500)] <EricDalquist> take the axe to user, profile, and layout tables
[09:56:15 CDT(-0500)] <athena> i don't think there's really any way to tell that is there? probably just need to check to see if they exist in the local system or not
[09:56:20 CDT(-0500)] <athena> yeah - it'll be really nice to fix that stuff
[09:56:35 CDT(-0500)] <athena> having real multi-layout support would let us write some really neat mobile interfaces
[09:56:44 CDT(-0500)] <EricDalquist> yeah, well we can also update person directory so that the up_person_dir data gets overlayed
[09:57:35 CDT(-0500)] <athena> overlayed with what kind of thing?
[09:57:49 CDT(-0500)] <EricDalquist> so you could set it up that even for a remote user
[09:58:02 CDT(-0500)] <EricDalquist> attributes defined in up_person_dir are included in their merged attributes
[09:58:11 CDT(-0500)] <athena> ah, gotcha
[09:58:13 CDT(-0500)] <EricDalquist> even overriding the ones from other sources
[09:58:20 CDT(-0500)] <athena> interesting thought
[09:58:22 CDT(-0500)] <EricDalquist> depending on how you configure it
[09:58:26 CDT(-0500)] <EricDalquist> yeah
[09:58:29 CDT(-0500)] <EricDalquist> not sure how useful that would be
[09:58:37 CDT(-0500)] <athena> i'd always assumed that local users got overlayed with external attributes now, to be honest - does that not actually work?
[09:58:50 CDT(-0500)] <athena> i think it would be a lot more useful to be able to modify external users
[09:58:54 CDT(-0500)] <EricDalquist> it all depends on how you have person directory setup
[09:59:15 CDT(-0500)] <athena> i think eventually we would really want to have write support for external person data sources
[10:01:20 CDT(-0500)] <athena> i'd still love to find a way to sensibly integrate that account management and self-signup code we wrote
[10:01:57 CDT(-0500)] <EricDalquist> yeah
[10:02:10 CDT(-0500)] <EricDalquist> person directory needs a big update some time soon
[10:02:19 CDT(-0500)] <athena> yeah
[10:02:28 CDT(-0500)] <EricDalquist> really what we need is a two-way aggregating LDAP proxy
[10:02:36 CDT(-0500)] <EricDalquist> that is essentially the path it is taking
[10:02:49 CDT(-0500)] <EricDalquist> an open source version of OIM (tongue)
[10:04:03 CDT(-0500)] <athena> (smile)
[10:04:49 CDT(-0500)] <EricDalquist> we're at the point here at UW where we need to add threading to person directory
[10:05:03 CDT(-0500)] <EricDalquist> we get user attributes from something like 12 different sources
[10:05:12 CDT(-0500)] <EricDalquist> some of it is chained, others are conditional, etc
[10:05:14 CDT(-0500)] <athena> oh wow
[10:05:19 CDT(-0500)] <EricDalquist> but a lot of it could be done in parallel
[10:05:28 CDT(-0500)] <athena> sounds like a pretty complex setup (smile)
[10:07:28 CDT(-0500)] <EricDalquist> we do stuff like "if you have role=student from LDAP then check database A if you're graduating and set that as an attribute, then if you are graduating check database B if you have filled out a survey and set that as an attribute"
[10:07:54 CDT(-0500)] <EricDalquist> then we use those "isGraduating" and "completedSurvey" attributes to conditionally permissions portlets
[10:08:04 CDT(-0500)] <EricDalquist> so stuff shows up/disappears based on your state
[10:08:44 CDT(-0500)] <athena> i feel like that's really powerful stuff that uportal can do that no one knows about
[10:09:06 CDT(-0500)] <EricDalquist> yeah
[10:09:07 CDT(-0500)] <EricDalquist> I know
[10:09:10 CDT(-0500)] <athena> dunno what we can do to make interesting features / use cases like that more visible
[10:09:20 CDT(-0500)] <EricDalquist> part of the problem is the configuration to do that is WAY to complex right now
[10:09:27 CDT(-0500)] <EricDalquist> or peson directory context is like 1500 lines
[10:09:35 CDT(-0500)] <EricDalquist> and it shouldn't be that verbose
[10:10:09 CDT(-0500)] <athena> crazy
[10:10:10 CDT(-0500)] <athena> yeah
[10:10:40 CDT(-0500)] <EricDalquist> it is really powerful though
[10:10:44 CDT(-0500)] <athena> definitely
[10:10:44 CDT(-0500)] <athena> t
[10:10:44 CDT(-0500)] <athena> hi
[10:10:44 CDT(-0500)] <athena> nk
[10:10:59 CDT(-0500)] <athena> things like that are why we probably need to think through any user account updating features pretty carefully
[10:11:08 CDT(-0500)] <athena> don't really want to break that kind of thing
[10:13:14 CDT(-0500)] <athena> once you finish the stax stuff we should also rewrite the site map as a portlet
[10:13:30 CDT(-0500)] <EricDalquist> yes
[10:13:36 CDT(-0500)] <EricDalquist> that would be good
[10:13:46 CDT(-0500)] <EricDalquist> so we had a local feature request for that
[10:13:51 CDT(-0500)] <EricDalquist> two views in the sitemap
[10:14:05 CDT(-0500)] <EricDalquist> one is "everything on my layout" and the other is "everything I can subscribe to"
[10:17:04 CDT(-0500)] <EricDalquist> so what else do we need in the resource server?
[10:17:10 CDT(-0500)] <EricDalquist> I got the dependencies updated
[10:17:13 CDT(-0500)] <EricDalquist> also simplified the filter
[10:17:21 CDT(-0500)] <athena> uhoh
[10:17:25 CDT(-0500)] <athena> is our wiki down/
[10:17:26 CDT(-0500)] <athena> ?
[10:17:44 CDT(-0500)] <EricDalquist> working for me ...
[10:18:27 CDT(-0500)] <athena> weird - i'm having trouble getting to both the wiki and jira
[10:18:39 CDT(-0500)] <athena> but jasig.org is fine
[10:18:46 CDT(-0500)] <EricDalquist> well they are different hosts
[10:18:50 CDT(-0500)] <EricDalquist> can you get to source.jasig.org?
[10:19:02 CDT(-0500)] <EricDalquist> www.jasig.org is WebChuckWeb
[10:19:05 CDT(-0500)] <athena> right - just meant i'm checking to make sure my browser works at all (tongue)
[10:19:12 CDT(-0500)] <athena> yes
[10:19:15 CDT(-0500)] <EricDalquist> wiki, issues, source, login, & developer are contegix
[10:19:28 CDT(-0500)] <EricDalquist> huh
[10:19:33 CDT(-0500)] <athena> source is ok
[10:19:37 CDT(-0500)] <EricDalquist> weird
[10:19:41 CDT(-0500)] <EricDalquist> try login.jasig.org
[10:20:40 CDT(-0500)] <athena> yep, that works ok
[10:21:04 CDT(-0500)] <athena> and we're back!
[10:21:04 CDT(-0500)] <athena> w
[10:21:05 CDT(-0500)] <athena> hate
[10:21:05 CDT(-0500)] <athena> ve
[10:21:05 CDT(-0500)] <athena> r.
[10:21:09 CDT(-0500)] <EricDalquist> strange
[10:21:14 CDT(-0500)] <athena> gah, dunno why irc is being weird today
[10:21:20 CDT(-0500)] <athena> just a temproary blip though i guess
[10:21:24 CDT(-0500)] <EricDalquist> sounds like you may be having network issues
[10:32:49 CDT(-0500)] <athena> yeah, actually think i am
[10:32:54 CDT(-0500)] * athena sighs
[10:32:57 CDT(-0500)] <athena> i hate comcast so much
[10:33:13 CDT(-0500)] <EricDalquist> so for resource server do you know what awills needed to add?
[10:35:32 CDT(-0500)] <athena> the two new fluid releases
[10:36:21 CDT(-0500)] <athena> so for ticket https://issues.jasig.org/browse/UP-2594
[10:36:47 CDT(-0500)] <athena> it looks like you're suggesting we have up_person_attr rows keyed each to a single person?
[10:37:18 CDT(-0500)] <athena> would it make sense at all to have an overall definition of valid user attributes?
[10:37:27 CDT(-0500)] <EricDalquist> right so have a data model of:
[10:37:27 CDT(-0500)] <EricDalquist> Person 1->N Attribute 1->N Value
[10:37:55 CDT(-0500)] <EricDalquist> like to restrict the attributes that people can edit?
[10:38:21 CDT(-0500)] <athena> well, just to have them defined at all
[10:38:29 CDT(-0500)] <EricDalquist> WOOHOO! New rendering pipline appears to be 100% functional!
[10:38:51 CDT(-0500)] <athena> seems like it's be annoying if you defined users with an email_address attribute and later wanted to change it to "mail" or whatever - you'd have to update every single user
[10:38:52 CDT(-0500)] <EricDalquist> well the code can do the JPA equivalent of "SELECT DISTINCT ATTR_NAME FROM UP_PERSON_ATTR"
[10:38:56 CDT(-0500)] <athena> and that's terrific (smile)
[10:39:02 CDT(-0500)] <EricDalquist> ah
[10:39:05 CDT(-0500)] <EricDalquist> I see
[10:39:12 CDT(-0500)] <EricDalquist> hrm
[10:39:24 CDT(-0500)] <athena> i'm not sure if any of this really matters since we don't actually typically really use that table (smile)
[10:39:26 CDT(-0500)] <EricDalquist> so you'd have a UI define the valid attribute s
[10:39:32 CDT(-0500)] <athena> so i'm probably overthinking it
[10:39:38 CDT(-0500)] <EricDalquist> yeah I'm not sure that is really needed
[10:39:43 CDT(-0500)] <athena> yeah
[10:39:46 CDT(-0500)] <EricDalquist> and if it is that could be done via some JPA
[10:39:56 CDT(-0500)] <athena> yes
[10:40:10 CDT(-0500)] <athena> do we have a use case for custom attributes?
[10:40:18 CDT(-0500)] <EricDalquist> I'm sure you could do something like: 'UPDATE UP_PERSON_ATTR SET ATTR_NAME="email" WHERE ATTR_NAME="mail"'
[10:40:20 CDT(-0500)] <EricDalquist> sure
[10:40:30 CDT(-0500)] <EricDalquist> so we publish a quickstart for our developers
[10:40:33 CDT(-0500)] <athena> yep, you definitely could
[10:40:42 CDT(-0500)] <athena> oh ok, yeah, it would be really nice for development
[10:41:04 CDT(-0500)] <EricDalquist> I put together a custom table + person_dir config so that developers can create local users with specific attributes
[10:41:21 CDT(-0500)] <EricDalquist> I think that is where we would see the most value from the attribute editing stuff
[10:41:41 CDT(-0500)] <EricDalquist> local developers wanting to have whatever random attribute their portlet needs set
[10:41:43 CDT(-0500)] <EricDalquist> and persisted
[10:42:27 CDT(-0500)] <EricDalquist> no caching aspects applied yet and page renders are sub-second (big grin)
[10:42:33 CDT(-0500)] <athena> awesome!
[10:42:45 CDT(-0500)] <EricDalquist> with probably 1/10th the total code
[10:42:49 CDT(-0500)] <athena> wow
[10:42:51 CDT(-0500)] <athena> that's fantastic
[10:43:11 CDT(-0500)] <EricDalquist> all our custom XHTML serializers can go away now
[10:43:44 CDT(-0500)] <EricDalquist> now to see if cernunnous works without xalan ....
[10:44:06 CDT(-0500)] <athena> sounds like a great change (wink)
[10:44:22 CDT(-0500)] <EricDalquist> also I think when we remove those serializers we might be able to remove xerces too
[10:44:34 CDT(-0500)] <EricDalquist> and just use the plain old JDK XML impls
[10:45:16 CDT(-0500)] <EricDalquist> so since I can't commit this yet to trunk but I don't want to loose the work I'm going to create a branch to use for the next week or so
[10:45:32 CDT(-0500)] <EricDalquist> hopefully less if not having xalan works out ok
[10:58:30 CDT(-0500)] <athena> sounds good
[10:58:40 CDT(-0500)] <athena> be great to be just using the jdk
[10:58:50 CDT(-0500)] <athena> so how'd you get around that bug anyway?
[11:00:35 CDT(-0500)] <EricDalquist> heh
[11:00:56 CDT(-0500)] <EricDalquist> so the StAX api has an event based reader and a cursor based reader
[11:01:13 CDT(-0500)] <EricDalquist> the pipeline is using the event based one because the event objects are immutable and can very easily be cached
[11:01:22 CDT(-0500)] <EricDalquist> but the bug only affects the event based reader
[11:01:38 CDT(-0500)] <EricDalquist> so I wrote an implementation of XMLStreamReader that wraps an XMLEventReader
[11:01:55 CDT(-0500)] <EricDalquist> there are one or two edge cases that weren't clear how to implement but we don't hit them right now
[11:02:11 CDT(-0500)] <EricDalquist> and if we do an exception with a "figure this out" message is thrown
[11:06:18 CDT(-0500)] <EricDalquist> but of course I then ran into another bug
[11:06:34 CDT(-0500)] <EricDalquist> doing XSLT -> StAX wrecks the namespaces
[11:07:11 CDT(-0500)] <EricDalquist> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6775588
[11:07:25 CDT(-0500)] <EricDalquist> bug open since late 2008 :/
[11:07:43 CDT(-0500)] <EricDalquist> so the XSLT is doing XSLT -> DOM -> StAX
[11:08:38 CDT(-0500)] <EricDalquist> which is pretty much what the XSLT does anyways but doing it explicitly gets around the bug
[11:12:37 CDT(-0500)] <athena> ah
[11:13:04 CDT(-0500)] <EricDalquist> so frustraiting that it took that much time and effort to work around
[11:13:15 CDT(-0500)] <EricDalquist> but in the end it shouldn't have any effect on performance
[11:13:25 CDT(-0500)] <EricDalquist> and all the fixes are encapsulated in the XSLTComponent
[11:23:15 CDT(-0500)] <EricDalquist> athena: how bad is it if the contents <script> tags aren't wrapped in the cdata stuff?
[11:23:40 CDT(-0500)] <athena> i think we actually did that to keep the XSLT from eating it, not for the HTML's sake
[11:23:47 CDT(-0500)] <EricDalquist> ah ok
[11:23:49 CDT(-0500)] <EricDalquist> good
[11:23:59 CDT(-0500)] <EricDalquist> the old custom serializes left that in the output
[11:24:02 CDT(-0500)] <EricDalquist> the new one does not
[11:24:08 CDT(-0500)] <EricDalquist> and I just wanted to make sure that wasn't an issue
[11:33:06 CDT(-0500)] <athena> do we really want the user attributes to be ordered?
[11:33:13 CDT(-0500)] <athena> or would just a map with ordered values be enough?
[11:33:46 CDT(-0500)] <EricDalquist> map with ordered values should be fine
[11:33:49 CDT(-0500)] <athena> ok
[11:34:01 CDT(-0500)] <athena> i think that'll make it easier to implement the person directory interface
[11:37:34 CDT(-0500)] <athena> hm, you have a favorite way to map a Map<String, List> in JPA?
[11:38:43 CDT(-0500)] <EricDalquist> no, its been a while since I've done that
[11:38:50 CDT(-0500)] <EricDalquist> lfuller might have some ideas
[11:39:09 CDT(-0500)] <athena> yeah i don't think about this quite often enough
[11:45:50 CDT(-0500)] * lfuller does JPA once every 6 months or so. Usually end up relearning far too much(sad)
[11:46:04 CDT(-0500)] <lfuller> am at home... and the book I like to refer to is at work right now.
[11:46:10 CDT(-0500)] <athena> oh well
[11:46:18 CDT(-0500)] <athena> (smile)
[11:46:24 CDT(-0500)] <lfuller> best of luck(smile)
[11:46:51 CDT(-0500)] <athena> thanks
[13:37:45 CDT(-0500)] <athena> should the attribute values be strings or objects?
[13:37:56 CDT(-0500)] <athena> looks like the persondir api uses objects these days
[13:38:15 CDT(-0500)] <EricDalquist> right but that has to handle things like returning a binary blob of an image from ldap
[13:38:24 CDT(-0500)] <EricDalquist> for this it can just be strings
[13:48:31 CDT(-0500)] <EricDalquist> hrm ... just realized that one interesting change is that a particular user may now have more than one cached entry in the structure and theme caches
[13:48:44 CDT(-0500)] <EricDalquist> that should help performance for active users (smile)
[13:58:35 CDT(-0500)] <athena> the API is kind of a pain if we keep it as explicit strings because you can't cast a List<String> to a List<Object>
[13:58:36 CDT(-0500)] <athena> blah
[14:00:04 CDT(-0500)] <EricDalquist> yay for the weirdness of java generics
[14:00:27 CDT(-0500)] <EricDalquist> its ugly but this works:
[14:00:27 CDT(-0500)] <EricDalquist> final List<String> a = new LinkedList<String>();
[14:00:27 CDT(-0500)] <EricDalquist> final List<Object> b = new LinkedList<Object>();
[14:00:27 CDT(-0500)] <EricDalquist> b.addAll(a);
[14:00:50 CDT(-0500)] <athena> yep
[14:00:53 CDT(-0500)] <athena> tha'ts what i have right now
[14:01:01 CDT(-0500)] <athena> we'll just have a bunch of extra code
[14:01:06 CDT(-0500)] <EricDalquist> yeah
[14:01:14 CDT(-0500)] <EricDalquist> one of the many things in PD that needs some thought
[14:01:29 CDT(-0500)] <EricDalquist> those APIs should probably be Map<String, List<? extends Object>>
[14:01:41 CDT(-0500)] <athena> yeah, that would make things easier most likely
[14:03:46 CDT(-0500)] <EricDalquist> https://source.jasig.org/uPortal/branches/working-rendering-pipeline/uportal-war/src/main/resources/properties/contexts/renderingPipelineContext.xml
[14:03:51 CDT(-0500)] <EricDalquist> its in SVN
[14:04:15 CDT(-0500)] <EricDalquist> I'll merge it back over once I've made sure nothing is overtly broken
[14:04:42 CDT(-0500)] <EricDalquist> the other thing that this switch will include is using a spring controller for the main portal entry point
[14:04:49 CDT(-0500)] <EricDalquist> and nuking the PortalSessionManager servlet
[14:05:25 CDT(-0500)] <athena> sounds great (smile)
[14:05:49 CDT(-0500)] <EricDalquist> wow 'ant initdb' just worked first try
[14:05:58 CDT(-0500)] <EricDalquist> apparently xalan is useless (tongue)
[14:07:48 CDT(-0500)] <athena> hurray!!
[14:07:52 CDT(-0500)] <athena> sounds like things are looking up
[14:07:55 CDT(-0500)] <EricDalquist> yes
[14:08:05 CDT(-0500)] <EricDalquist> feeling much better about all of this than I was a few days ago
[14:09:30 CDT(-0500)] <EricDalquist> I think I might see if I can remove xerces as well tonight ...
[14:09:41 CDT(-0500)] <EricDalquist> as much as I am a huge "use a library for it" fan
[14:09:48 CDT(-0500)] <EricDalquist> un-needed libraries are annoying
[14:14:14 CDT(-0500)] <b-rock> greetings uPortal devs: does someone here know how to reset the users theme/skin directly in the db? I've switched to a different theme/skin in my profile and have lost the link to swithc back.
[14:15:27 CDT(-0500)] <EricDalquist> I think it might be in UP_SS_USER_PARM
[14:23:27 CDT(-0500)] <b-rock> ok. I'll check there. Thanks EricDalquist
[14:25:07 CDT(-0500)] <b-rock> that was it. Thanks.
[15:20:54 CDT(-0500)] <athena> EricDalquist: what's our current process for deploying snapshot artifacts?
[15:20:58 CDT(-0500)] <athena> are we using bamboo for that?
[15:26:31 CDT(-0500)] <EricDalquist> yeah
[15:26:33 CDT(-0500)] <EricDalquist> for the uportal stuff
[15:26:44 CDT(-0500)] <EricDalquist> anyone with a sonatype account can do it do
[15:26:48 CDT(-0500)] <EricDalquist> there is no staging for snapshots
[15:26:55 CDT(-0500)] <EricDalquist> 'mvn deploy' will push them uot
[15:31:18 CDT(-0500)] <Bananobot> Hey guys. I'm back with a few additional questions about uPortal vs. Liferay. Basically, is there any significant difference in their implementations of the following: 1. The ability for multiple portlets to work together as a single user interface flow. 2. The flexibility of user access control. 3. The look-and-feel customizability.
[16:02:25 CDT(-0500)] <athena> oh ok, so we can still deploy all the portlets via "mvn deploy"?
[16:02:51 CDT(-0500)] <athena> Bananobot: uportal's look and feel is completely customizable at a number of levels
[16:03:18 CDT(-0500)] <athena> and you can have potentially different experiences in the same portal - for instance, we present the same layout in a very different way on a mobile device
[16:04:25 CDT(-0500)] <athena> uportal also has a very powerful permissions system
[16:04:42 CDT(-0500)] <athena> it's not very intuitive right now, but we're in the middle of completely redesigning the user interface for permissions administration
[16:12:49 CDT(-0500)] <Bananobot> athena: Thanks. I asked the same thing in the Liferay channel, but it appears to be dead.
[16:12:57 CDT(-0500)] <athena> sorry to hear that!
[16:13:19 CDT(-0500)] <athena> from what i know, liferay's theme is built out of a combination of velocity templates and JSP files
[16:14:04 CDT(-0500)] <athena> i don't really remember all the details, but you can at least assign different themes to different user communities and such
[16:14:19 CDT(-0500)] <athena> uportal's rendering stack is actually pretty interesting
[16:14:48 CDT(-0500)] <athena> layouts are represented as nested folder structures in XML, then transformed into a more semantic XML via a "structure" transform
[16:14:54 CDT(-0500)] <Bananobot> Somewhere, I read someone complaining that uPortal's theming system was so robust that it was difficult to develop a complete theme.
[16:14:55 CDT(-0500)] <athena> then to HTML via a "theme" transform
[16:15:04 CDT(-0500)] <Bananobot> Something about having more "layers" than Liferay
[16:15:09 CDT(-0500)] <athena> yes, definitely more layers
[16:15:29 CDT(-0500)] <athena> the default theme has improved a ton in the last few years though, and it's much easier to customize
[16:15:35 CDT(-0500)] <athena> and it's much easier to customize via CSS
[16:15:52 CDT(-0500)] <athena> so at this point, rather than writing new themes, many schools actually just tweak the XSLT a bit and then change the CSS
[16:16:09 CDT(-0500)] <athena> there are three full skins to start from, plus customized views for iphone and android
[16:16:24 CDT(-0500)] <athena> i don't know if you've taken a look at the mobile support at all or if that kind of thing interests you
[16:18:23 CDT(-0500)] <athena> you don't actually have to understand the internals to skin uportal, but there are some really interesting things you can do if you run into a complete use case
[16:18:46 CDT(-0500)] <Bananobot> Mobile support actually came up during a meeting today. I said I believe that uPortal has a mobile-specific layout and somehow conveys to the portlets that it's in a mobile environment
[16:19:17 CDT(-0500)] <athena> we do have some portlets with mobile support - right now most of them inspect the browser's user agent themselves, but it's also possible to send the in-use theme name to the portlet
[16:19:21 CDT(-0500)] <Bananobot> How does uPortal detect that it needs to use the mobile version?
[16:19:55 CDT(-0500)] <athena> there's a file that contains mappings between browser user agents and user profiles
[16:20:04 CDT(-0500)] <Bananobot> Ah, so it's ua-string-based
[16:20:09 CDT(-0500)] <athena> yes
[16:20:26 CDT(-0500)] <athena> though you could probably implement custom behavior if you wanted
[16:20:42 CDT(-0500)] <athena> there's a demo of the mobile functionality here if you want to see what it looks like: http://www.youtube.com/watch?v=NshUldCAyJ8
[16:20:42 CDT(-0500)] <Bananobot> Wouldn't it be nice if browsers simply sent an HTTP header with the current pixel dimensions of the viewport? (tongue)
[16:20:50 CDT(-0500)] <athena> yes (smile)
[16:20:58 CDT(-0500)] <athena> since that video, we've added a separate android theme
[16:21:06 CDT(-0500)] <Bananobot> With CSS 3 media queries, we'll be able to do some of that
[16:21:24 CDT(-0500)] <Bananobot> I know Opera supports media queries. I don't know about other browsers
[16:21:38 CDT(-0500)] <athena> the new mobile themes do make use of some css3 - rounded corners and gradients and such
[16:21:52 CDT(-0500)] <athena> so a key thing that differentiates uportal from some other portals is the way user layouts work
[16:22:26 CDT(-0500)] <athena> you can define default layout fragments (typically a single tab, or something like that), that users then receive based on their group membership
[16:22:50 CDT(-0500)] <athena> and you can define whether users should be allowed to modify that layout or not, but even if they do, they'll still continue to receive updates
[16:22:50 CDT(-0500)] <athena> a
[16:23:21 CDT(-0500)] <athena> lot of other portals make you choose between being able to administratively update user layouts and letting users modify their layouts
[16:23:39 CDT(-0500)] <athena> so you can have a student tab that all students inherit by default, that they can add content to, but that you can also add new content to later on
[16:23:44 CDT(-0500)] <Bananobot> So it's kind of a diff-based layout approach?
[16:24:08 CDT(-0500)] <athena> i think that's a fair description
[16:24:49 CDT(-0500)] <Bananobot> In our specific case, I'm not sure that we plan to allow users to customize their layouts, but it's interesting to know
[16:25:35 CDT(-0500)] <athena> even if you don't choose to allow customization, i think the ability to determine which content users receive at a tab level is pretty useful
[16:25:55 CDT(-0500)] <Bananobot> Can a portlet completely hide itself if certain custom portlet-specific conditions are met?
[16:27:15 CDT(-0500)] <athena> hmm
[16:27:16 CDT(-0500)] <Bananobot> For example, if the portlet has to authenticate with a remote server, and that authenticated account has a certain status on the remote server, could the portlet come back and go, "Oh, it seems you aren't allowed to see this. HIDE TEH PORTLET!"
[16:28:28 CDT(-0500)] <athena> i don't think that out of the box there's a way for the portlet itself to indicate to the portal that the portlet is unauthorized, since it's running in a different context
[16:28:48 CDT(-0500)] <athena> most of the authorization decisions that typically result in content being hidden are made at the portal level
[16:28:51 CDT(-0500)] <Bananobot> So, the title and portlet controls would still appear?
[16:28:58 CDT(-0500)] <Bananobot> Even if the portlet has no output?
[16:29:10 CDT(-0500)] <athena> in the default behavior, yes, though i'm sure you could find a way to get what you want working
[16:29:48 CDT(-0500)] <athena> and you might also consider finding a way to indicate to the portal that certain accounts do or don't have a status on the remote server, since that might be interesting role information anyway
[16:30:35 CDT(-0500)] <Bananobot> You can hide portlets based on custom user account fields, right?
[16:31:18 CDT(-0500)] <athena> yes
[16:31:41 CDT(-0500)] <Bananobot> If the portlet sets that custom field, is it too late for the setting to go into affect?
[16:31:42 CDT(-0500)] <athena> there's actually a way to even create groups based on user account fields
[16:32:14 CDT(-0500)] <athena> so typically i think most institutions would collect all that information at login time, then assign users to groups based on those attributes
[16:32:31 CDT(-0500)] <athena> then permission portlets by group
[16:33:10 CDT(-0500)] <athena> typically a portlet wouldn't be able to affect that field, since it's in a separate application context
[16:33:31 CDT(-0500)] <Bananobot> I think the idea is we want to step the user through a process that gradually opens up access to additional portlets as they progress.
[16:33:43 CDT(-0500)] <athena> eric was actually in the channel earlier this morning talking about some interesting things they've done with user attributes, where user attributes are assigned based on a number of conditional tests at login time
[16:34:07 CDT(-0500)] <athena> ah, interesting
[16:34:43 CDT(-0500)] <Bananobot> Because some portlets depend on information gathered from user input in other portlets
[16:35:03 CDT(-0500)] <athena> makes sense
[16:35:08 CDT(-0500)] <athena> i think you could set something like that up
[16:35:11 CDT(-0500)] <Bananobot> And we don't want the user to see a bunch of empty placeholder boxes
[16:35:24 CDT(-0500)] <athena> definitely makes sense
[16:35:47 CDT(-0500)] <athena> i'm sure you could find a way to implement that
[16:36:49 CDT(-0500)] <Bananobot> That's pretty much the gist of the first two questions I asked today. We're curious about how uPortal and Liferay compare when it comes time to implement that.
[16:38:02 CDT(-0500)] <Bananobot> Unfortunately, #liferay is pretty much dead except for someone promising that a particular Liferay developer pops in every once in a while.
[16:39:30 CDT(-0500)] <athena> we don't have a huge user population in IRC, but there are generally at least a few people around
[16:39:47 CDT(-0500)] <athena> i actually think the most interesting thing about uportal is that it's very extensible
[16:39:48 CDT(-0500)] <athena> l
[16:39:48 CDT(-0500)] <athena> ots
[16:40:05 CDT(-0500)] <athena> lots of spring-configured implementations that run against pretty well-thought out interfaces
[16:40:23 CDT(-0500)] <athena> i've generally found that there's usually a sane way to implement most functionality that i've wanted
[16:41:41 CDT(-0500)] <athena> makes things fun (smile)
[16:45:54 CDT(-0500)] <Bananobot> I just signed up for an account on Liferay.com to use their forums, and they sent me a confirmation e-mail containing my password in plain text. Please tell me uPortal doesn't do that. >_<
[16:51:39 CDT(-0500)] <athena> no
[16:51:46 CDT(-0500)] <athena> we solve that by not having forums (smile)
[16:51:55 CDT(-0500)] <athena> though our email lists generally serve the same purpose
[16:52:14 CDT(-0500)] <athena> uportal doesn't have account signup out of the box, though it does have an incubating portlet that provides self-signup capabilities