9:10 a.m.
On Tue, 2012-03-06 at 21:11 -0500, Ken Finnigan wrote:
Matt,
I've read through all the Mobile specs you've written for GateIn, and here is my
feedback:
Thanks, yeah, there are a few typos and such in the specs right now,
they are more of a draft to see what others feedback is before making
them more concrete. Thanks for looking over it, comments in line below.
• Mobile Detection
• Introduction
• Last paragraph has a typo, think the "m" needs to be a
comma in "content between devicesm different content"
•
Use Cases
• 2nd bullet has an "except" that should be "expect"
•
Replaceability
• Agree that we need something smart enough to be able to
determine whether the filter is active to prevent UI admin display,
while also providing a way to turn the whole thing off. If there's a
configuration setting for turning on and off, would it be a case of
the filter is always active, but just skips over itself if the
configuration setting is deactivated? This would enable it to be
reactivated without necessitating a portal restart, I'd imagine. There
may be a dynamic/fancy way of doing it too
We shouldn't really use filters anymore. The navigation controller now
controls how portal urls are mapped. I have already updated my prototype
to use a WebRequestHandler instead.
I don't know if it makes sense for it to be completely plugable and
remove all trace of it from the admin ui if its removed (nor have I
started to create the ui components yet). It will be setup so that its
disabled by default and will require either an xml configuration file to
be configured, or enabled through the admin ui.
The logic for determining redirects will be a service, and the admin can
write their own service implementation to handle this if they want to
use a custom solution. The device detection will also be configurable as
well, so the admin can select exactly what they want to check for.
If someone wants to have their own completely different configuration,
they are also free to use their own custom filter or some other
mechanism to handle it. They would just need to make sure the built in
one is disabled.
Mobile Redirection and Mirroring
• Workflow
• Definitely think that the logic paths to go from
original url to destination url need to be cached. Maybe add that as
first step in flow to check cache for existing mapping from orig->dest
for matching orig. Then updates to mappings by admin could cause flush
of cache to that part of the tree impacted. ie. admin changing
mappings for portal/foo/x/y will flush cache for portal/foo/x/y and
anything lower, but cache for portal/foo/x and other children of x
still remain
Yes, caching needs to be done.
Mobile Manual Redirection Selection
• I think there should be the option for the user to decide
whether this alternative site will always be redirected to
(cookie/session is updated), or only this one occasion (session is
updated)
I disagree, we should only give the user the option to always redirect
but make it easy for them to switch back.
Mobile Look and Feel
• Is there a link for the touch based gestures at the end of
the Introduction yet?
The look and feel is a bit farther away and has other things which need
to be fixed before we get into things like gestures. Gestures are not
going to be supported at least for the first couple of releases of this.
Its more important to get the device detection and redirection working
properly.
•
Mobile Portlet Development
• Use Cases
• Look and Feel has typo of "fell" instead of "feel"
•
General
• Could the Navigation Controller be leveraged to provide any
of this URL mapping or routing that would be required in switching
between desktop/tablet/mobile?
Yes, I am using the navigation controller now and using some internal
services to determine mappings and routings. For now I am concentrating
on just allowing switching between sites on the same portal which makes
things a lot easier. I will have to see later if there is much of a need
to have redirection between separate distinct portals or between other
separate websites (between separate distinct portals becomes a bit
tricky since I don't think we have remote capabilities to detect if a
node exists or not).
Given the current architecture of the platform, ie. not geared for
mobile, I believe the specs you've outlined are a great step into the
portal supporting mobile. Impressed with the various aspects that
you've covered thoroughly.
Ken
4703
days inactive
4703
days old
0 comments
1 participants
participants (1)
-
Matt Wringe