[Plone-developers] plone.app.toolbar and moving the management ui into overlays
Izak Burger
I've been doing some work on moving the plone editing and
administration pages to overlays lately, you will find this in the
bootstrap-overlays branch of p.a.toolbar. It is based off twitter
bootstrap and as a result it requires all sorts of bleeding edge
versions, you will need plone.app.jquery with jquery 1.7 enabled (I
have my own fork of that presently).
I have been trying to keep this as generic as possible. I've worked
with jquerytools' overlays before, but that doesn't feel generic
enough for what I want to do here, and I have to redo it for
bootstrap-based overlays in any case. The problem I have to solve is
this:
1. Sometimes when you click on a link, for example View, you don't
want it to open in an overlay at all, but other times (Edit, Contents,
Sharing) you want it to open in an overlay.
2. Links inside the overlay should generally load the linked resource
into the same overlay, for example, when you have folder_contents open
in an overlay, you want folderish items to open in the same overlay.
But when you click on a non-folderish item, it should drop out of the
overlay.
3. When there are forms inside the overlay, the result of posting that
form (which is done in ajax using the jq form plugin) should generally
go back into the overlay. But not always, sometimes the result should
go to the main window. Or the main window should reload, redirected
elsewhere, or perhaps nothing needs to happen.
I have a solution for 1: I defined a list of css selectors of items
that should not open in an overlay. When you click one of those, it
opens straight in the browser window. I'm thinking this should perhaps
have some kind of plone.registry/configlet interface so you (or your
third-party product) can add more.
I also think I can use a similar solution for 2. I might be able to
deduce folderish items using their css class, but though I see this
working very well with contenttype-folder, it's not going to work with
other folderish content types. I suppose as long as it works for the
default plone types and you can add your own, that should be fine.
With 3 I have no plan yet. jquerytools handles this case in a very
explicit manner: You tell it which form, and what to do if the form
isn't there, and it concerns itself only with that form. I'd like
things to work even if there are more than one form on a page, or
several different buttons like folder_contents has. One thing that
might work is a sort of registry with all the information you'd
normally pass to jqueryTools' ajaxForm so that these can be applied
when such a form is encountered in an overlay.
It this too elaborate a plan? I would welcome any ideas :-)
regards,
Izak
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Plone-developers mailing list
Plone-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plone-developers
Laurence Rowe
Great to hear you are working on CMSUI!
On 6 March 2012 22:53, Izak Burger <iz...@upfrontsystems.co.za> wrote:
> Hi all,
>
> I've been doing some work on moving the plone editing and
> administration pages to overlays lately, you will find this in the
> bootstrap-overlays branch of p.a.toolbar. It is based off twitter
> bootstrap and as a result it requires all sorts of bleeding edge
> versions, you will need plone.app.jquery with jquery 1.7 enabled (I
> have my own fork of that presently).
Are you planning to use the editing / admin stuff from p.a.cmsui or
the current plone forms here?
> I have been trying to keep this as generic as possible. I've worked
> with jquerytools' overlays before, but that doesn't feel generic
> enough for what I want to do here, and I have to redo it for
> bootstrap-based overlays in any case. The problem I have to solve is
> this:
>
> 1. Sometimes when you click on a link, for example View, you don't
> want it to open in an overlay at all, but other times (Edit, Contents,
> Sharing) you want it to open in an overlay.
Can you be more specific about where these links are? The View object
action doesn't really make sense in the context of CMSUI and should
probably be hidden.
> 2. Links inside the overlay should generally load the linked resource
> into the same overlay, for example, when you have folder_contents open
> in an overlay, you want folderish items to open in the same overlay.
> But when you click on a non-folderish item, it should drop out of the
> overlay.
> 3. When there are forms inside the overlay, the result of posting that
> form (which is done in ajax using the jq form plugin) should generally
> go back into the overlay. But not always, sometimes the result should
> go to the main window. Or the main window should reload, redirected
> elsewhere, or perhaps nothing needs to happen.
>
> I have a solution for 1: I defined a list of css selectors of items
> that should not open in an overlay. When you click one of those, it
> opens straight in the browser window. I'm thinking this should perhaps
> have some kind of plone.registry/configlet interface so you (or your
> third-party product) can add more.
>
> I also think I can use a similar solution for 2. I might be able to
> deduce folderish items using their css class, but though I see this
> working very well with contenttype-folder, it's not going to work with
> other folderish content types. I suppose as long as it works for the
> default plone types and you can add your own, that should be fine.
I think opening a link in an overlay should be opt-in rather than
opt-out as this best follows the principle of least surprise for an
integrator creating new overlays. Each overlay should know which of
it's links should stay within the overlay and set an appropriate class
on that element. The toolbar javascript can then go through and
capture the appropriate links to keep them within the overlay.
The folder_contents view for instance knows which items are really
folders and would be able to set an appropriate class.
> With 3 I have no plan yet. jquerytools handles this case in a very
> explicit manner: You tell it which form, and what to do if the form
> isn't there, and it concerns itself only with that form. I'd like
> things to work even if there are more than one form on a page, or
> several different buttons like folder_contents has. One thing that
> might work is a sort of registry with all the information you'd
> normally pass to jqueryTools' ajaxForm so that these can be applied
> when such a form is encountered in an overlay.
You could encode this on the forms themselves using HTML5 data-
attributes. In general, the fewer registries we have the better. An
integrator should be able to create an overlay in a self-contained
template without having to make setting registrations.
> It this too elaborate a plan? I would welcome any ideas :-)
Hope the above helps!
Laurence
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
jure
On 03/07/2012 01:04 AM, Laurence Rowe wrote:
> Are you planning to use the editing / admin stuff from p.a.cmsui or
> the current plone forms here?
I would really, really like to see the nice github-like folder listing
view that was included in the cmsui instead of the default plone folder
listing, it makes updating the structure so much easier..
cheers,
ibi
> Virtualization& Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Plone-developers mailing list
> Plone-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plone-developers
--
Jure Cerjak
Termitnjak d.o.o.
Ulica Janeza Pavla II 007, 1000 Ljubljana
Web: http://www.termitnjak.com
Tel: +386 (0)40 162-740
Email: jce...@termitnjak.si
Izak Burger
Trying again.
On Wed, Mar 7, 2012 at 2:18 AM, jure <jce...@termitnjak.si> wrote:
> I would really, really like to see the nice github-like folder listing
> view that was included in the cmsui instead of the default plone folder
> listing, it makes updating the structure so much easier..
I would probably have to rethink this, you are not the first to
suggest that a nicer interface would be, uuuhm, nice. Not sure if
that's a tautology :-) My first instinct was to simply overlay the
current folder_contents.
p.a.toolbar uses the actions defined in portal_actions, and some of
them will come with plone-like views, so whatever solution I come up
with must at least support those. I do agree that perhaps a nicer
folder_contents view is in order, and perhaps the "new" version of
cmsui (and some point Rok and I thought that cmsui might even be
unnecessary) need only provide overriden views that look nice.
What needs to be simple with as little surprises as possible, as
Laurence explained, is adding a new action to portal_actions. If your
new action brings up a view, it should work "as expected" by default.
Perhaps the default shoult be not to overlay it at all? It should also
be easy to provide an overlay for the new view you added, so adding a
new overlay becomes:
1. Add an action to portal_actions
2. Add some javascript/whatever to overlay your view properly.
Thoughts?
regards,
Izak
Jean Jordaan
> I've been doing some work on moving the plone editing and
> administration pages to overlays lately,
This could be cool, but please don't break all my comfy old hacks. E.g.
sometimes I want to right-click open the edit view of a document while keeping
the rendered view visible. Or I right-click open the "Add xxx" link 5 times, if
my connection is slow and I want the other four add forms to render while I'm
filling in the first. And right now I'm troubleshooting a Plone on a remote
private network using lynx, which is working great. (I was partly testing
whether my nginx vhost configuration works on the private network, so tunneling
to a port wouldn't have worked.)
Also, I trust your overlays don't throw away content like the ones on plone.org
do: https://dev.plone.org/ticket/12135 ... smcmahon's comment seems ominous.
Sorry to be curmudgeonly ... my point is just that basic browser mechanics
makes for a powerful environment. Things that look cool from one perspective
often close off other perspectives.
Github gets a lot of kudos for coolness, but I can't select text from the lists
of issues in their issue trackers (I have to switch to source view to select),
I can't scroll using the up/down arrows (it moves the issue focus instead), and
I can't navigate using Firefox's sublime typeaheadfind (because '/' focuses the
issue search field).
Just one more perspective to keep in mind ;-)
--
jean . .. .... //\\\oo///\\
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
Izak Burger
Hoe gaan dit? :-)
On Wed, Mar 7, 2012 at 1:53 PM, Jean Jordaan <jean.j...@gmail.com> wrote:
> This could be cool, but please don't break all my comfy old hacks. E.g.
I use the same tricks that jquerytools use. You replace the
clickhandler on an item, so that a left click now does something else.
But the anchor still has its original href attribute, so
middle-clicking (on linux/firefox) still opens a new tab, you can
still do all the things you're used to. I also do that thing where I
open four tabs so they can load so long... internet in Africa huh? :-)
regards,
Izak
jure
This reminds me: can we have a "Save and add another" button on the add
form? If you need to add a lot of items it's really annoying to be
redirected to the newly created item, then navigating to parent folder
and clicking on the "Add new..", selecting the portal type once again
etc. . I could create a custom action, but maybe this should be in the core?
cheers,
ibi
On 03/07/2012 12:53 PM, Jean Jordaan wrote:
> Hi Izak& all
>
>> I've been doing some work on moving the plone editing and
>> administration pages to overlays lately,
> This could be cool, but please don't break all my comfy old hacks. E.g.
> sometimes I want to right-click open the edit view of a document while keeping
> the rendered view visible. Or I right-click open the "Add xxx" link 5 times, if
> my connection is slow and I want the other four add forms to render while I'm
> filling in the first. And right now I'm troubleshooting a Plone on a remote
> private network using lynx, which is working great. (I was partly testing
> whether my nginx vhost configuration works on the private network, so tunneling
> to a port wouldn't have worked.)
>
> Also, I trust your overlays don't throw away content like the ones on plone.org
> do: https://dev.plone.org/ticket/12135 ... smcmahon's comment seems ominous.
>
> Sorry to be curmudgeonly ... my point is just that basic browser mechanics
> makes for a powerful environment. Things that look cool from one perspective
> often close off other perspectives.
>
> Github gets a lot of kudos for coolness, but I can't select text from the lists
> of issues in their issue trackers (I have to switch to source view to select),
> I can't scroll using the up/down arrows (it moves the issue focus instead), and
> I can't navigate using Firefox's sublime typeaheadfind (because '/' focuses the
> issue search field).
>
> Just one more perspective to keep in mind ;-)
>
--
Jure Cerjak
Termitnjak d.o.o.
Ulica Janeza Pavla II 007, 1000 Ljubljana
Web: http://www.termitnjak.com
Tel: +386 (0)40 162-740
Email: jce...@termitnjak.si
Laurence Rowe
I think all of the object action buttons should bring up an overlay.
There is only ever a single primary view of a content object (which
you might choose from the display dropdown.) The others are all about
metadata and loading them in an overlay means that a user does not
lose context while editing / viewing the metadata. If you really don't
want them to open in an overlay then you should put them somewhere
else (perhaps in document actions.)
We should be more concerned with building something consistent than
making it infinitely configurable (and complex.) As an escape route,
you could always override the behaviour of the viewlet rendering the
object actions and add/remove a class from the link that prevents the
overlay click capturing.
Laurence
Martin Aspeli
+100
Izak Burger
A bit of a progress report. There has been quite a lot of action on
this, Ross Patterson has done a lot of work and I've received input
from Laurence, Jean, Ibi and Roche. The product
is almost usable :-)
Many bugs have been fixed, plone tabs are now properly initialised
inside the overlay, and tinymce works as well. The overlayed views are
unthemed (I think there is one small bug left), so that changes that
p.a.theming might make to your content does not affect the overlays
(use case: some designs might strip out the breadcrumbs, which you
want in the overlay).
The overlay component itself is now in the iframe and no longer in the
plone_footer of the parent window. This means the overlay gets its css
from the iframe and not from the original document. This is good, but
it also meant loading all of plone's css and javascript into the
iframe, which impacted the rendering of the toolbar and made it all
green. I suspect it might be possible to strip this down somewhat.
If I understand the concept correctly, the idea is that the overlays
will be heavy with javascript and css, while the underlying site will
contain only the javascript and css actually in use and/or intended by
the designer, that is, the heavy old plone interface lives in the
iframe, the light beautiful theme lives in the main window.
>From a hot South Africa, at 01:24, I bid thee Good Night.
Izak
Laurence Rowe
Great news. It would be really helpful if you and Rok could share the
buildouts you are using to work on this. It would be really helpful to
see it in action.
Laurence
Jean Jordaan
Sommer lekker man.
> I use the same tricks that jquerytools use.
Sounds like you're on top of things.
Curious: would it be practical to switch between editing using an
overlay and editing using another browser window? So that the rendered
view is not obscured?
> I also do that thing where I
> open four tabs so they can load so long... internet in Africa huh? :-)
Also tethered internet on GPRS, and in various parts of South-East Asia.
--
jean . .. .... //\\\oo///\\
------------------------------------------------------------------------------
Roché Compaan
> Great news. It would be really helpful if you and Rok could share the
> buildouts you are using to work on this. It would be really helpful to
> see it in action.
I attach a minimal buildout I extracted from the project Izak and I
are currently working on. Note that we are using a forked
plone.app.jquery to pull in jquery 1.7. Once 1.6 and 1.7 releases have
been made for plone.app.jquery, the fork can be removed.
Btw Izak, it would make more sense to do this as a branch on
plone.app.jquery, rather than fork it.
--
Roché Compaan
Upfront Systems http://www.upfrontsystems.co.za
Izak Burger
> Btw Izak, it would make more sense to do this as a branch on
> plone.app.jquery, rather than fork it.
True, and I did try that first, but I do not have commit rights on
p.a.jquery. I think Ross also tried and found that he doesn't have
rights either.
Roché Compaan
> The overlay component itself is now in the iframe and no longer in the
> plone_footer of the parent window. This means the overlay gets its css
> from the iframe and not from the original document. This is good, but
> it also meant loading all of plone's css and javascript into the
> iframe, which impacted the rendering of the toolbar and made it all
> green. I suspect it might be possible to strip this down somewhat.
I have fixed most of this now, so the toolbar looks much less
psychedelic now :-)
--
Roché Compaan
Upfront Systems http://www.upfrontsystems.co.za
------------------------------------------------------------------------------
garbas
> p.a.jquery. I think Ross also tried and found that he doesn't have
> rights either.
for some reason p.a.jquery package was not in Develpers github team. This
was fixed. Ross already created 1.7 branch.
i've created toolbar-only.cfg[1] which i use to test p.a.toolbar
independently from p.a.deco. but it uses master branch from p.a.toolbar.
about merging your branch to master i'll write in separate email since
your changes break p.a.deco.
[1] https://github.com/plone/buildout.deco/blob/master/toolbar-only.cfg
--
Rok Garbas
--
View this message in context: http://plone.293351.n2.nabble.com/plone-app-toolbar-and-moving-the-management-ui-into-overlays-tp7350279p7361748.html
Sent from the Core Developers mailing list archive at Nabble.com.
Ed Manlove
> i've created toolbar-only.cfg[1] which i use to test p.a.toolbar
> independently from p.a.deco. but it uses master branch from p.a.toolbar.
> about merging your branch to master i'll write in separate email since
> your changes break p.a.deco.
>
>
> [1] https://github.com/plone/buildout.deco/blob/master/toolbar-only.cfg
>
>
> --
> Rok Garbas
>
Talking about testing, I've been working on the selenium2library using
robotframework for UI testing within Plone [1,2]. This is updating the
work done at the last Plone Conference Sprints to use the newer Selenium
2/WebDriver testing framework. Noticing the flurry of activity
concerning the toolbar/jQuery/Plone UI, I've started to create a
buildout with robotframework-selenium2library so we can write some
acceptance tests in support of your work.
I've started with the buildout.cfg that Roche posted yesterday but can
easily switch to the, above mentioned, toolbar-only.cfg. This would
probably be better as I can fork (or branch) and share it easier. Any
thoughts?
Ed
[1] https://dev.plone.org/ticket/11708
[2] https://github.com/gotcha/plone-robot-documentation
garbas
>
> A bit of a progress report. There has been quite a lot of action on
> this, Ross Patterson has done a lot of work and I've received input
> from Laurence, Jean, Ibi and Roche. The product
> is almost usable :-)
>
> Many bugs have been fixed, plone tabs are now properly initialised
> inside the overlay, and tinymce works as well. The overlayed views are
> unthemed (I think there is one small bug left), so that changes that
> p.a.theming might make to your content does not affect the overlays
> (use case: some designs might strip out the breadcrumbs, which you
> want in the overlay).
>
> The overlay component itself is now in the iframe and no longer in the
> plone_footer of the parent window. This means the overlay gets its css
> from the iframe and not from the original document. This is good, but
> it also meant loading all of plone's css and javascript into the
> iframe, which impacted the rendering of the toolbar and made it all
> green. I suspect it might be possible to strip this down somewhat.
>
> If I understand the concept correctly, the idea is that the overlays
> will be heavy with javascript and css, while the underlying site will
> contain only the javascript and css actually in use and/or intended by
> the designer, that is, the heavy old plone interface lives in the
> iframe, the light beautiful theme lives in the main window.
>
i've quickly reviewed your changes and we already talk over github about
your
changes. i still have to review the overlay part more in detail but i
stumble
uppon the change that i think ross did. and that was changing how iframe is
created.
to explain a bit more.
p.a.toolbar intention was to get common code base for toolbar which was
created
in both p.a.cmsui and p.a.toolbar. initially i took cmsui toolbar and add
bits
of deco toolbar, but once i've added more javascript / css files to toolbar
iframe that initial blinking was getting bigger and bigger (even if
resources
were cached) what i found later with test and trial is that if you generate
iframe with javascript you can avoid this growing of initial blink and
minimize
it to minimum. and this is how i come up with toolbar.js which handles
creation
of iframe and placing buttons from json that it gets from plone.
there was also another point why i took this "javascript approach". one of
the
initial goals i had with deco was to create it platform independent. meaning
that you could easily use deco in any other project with other frameworks.
this
would be especially easy with pyramid since plone.tiles is plone
independant.
could be even possible with django, since i put all the logic of toolbar
into
javascript.
now the change that you (and ross) did is that you removed the code which is
creating iframe and you create iframe with viewlet. which means you're back
to
the same point where cmsui was. only complaint that i got, was from ross
saying
that code looked unmaintainable, which he was referring to javascript code.
now by opinion code looks nice, or at least ok and is also tested. not sure
how much the coverage is but i tried to cover all the cases i could though
of,
i might even bet that its abot 80%.
i believe that getting overlays to work would only need some javascript
work.
not that i believe i'm actually sure about it. i dont think i want to merge
your branch at this point, since i also have to look (in comming week) at
what
you've done overlays and then come back to you about it.
ranting (dont have to read):
i'm kinda getting frustrated that a lot of plone developers run away from
javascript and they only do it if they have to glue some piece of user
experience together. ofcourse on the end we have this crappy javascript that
we
have to deal with. snippets of javascript laying all around making them hard
to
reuse. seriusly i dont blame you that you hate it. its a pain in the ass to
do
something special with javascript and plone.
i think that this cmsui is our big chance that we fix all the ugly
javascript
that we have been accumulating from last 8 years.
and don't let me mention our "testing" of javascript. seriusly guys,
javascript
_CAN_ be nice and _CAN_ be fun to work with, especially if its tested.
i know that all this ranting, doesn't solve anything but i have to let it
out.
--
View this message in context: http://plone.293351.n2.nabble.com/plone-app-toolbar-and-moving-the-management-ui-into-overlays-tp7350279p7361815.html
Sent from the Core Developers mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Izak Burger
> now the change that you (and ross) did is that you removed the code which is
> creating iframe and you create iframe with viewlet. which means you're back
> to
> the same point where cmsui was. only complaint that i got, was from ross
> saying
> that code looked unmaintainable, which he was referring to javascript code.
I think Ross (and definitely myself) was unaware of some of these
design criteria. Looking at it from a plain zope/plone point of view
(in other words, no platform-independence taken into account), and
take this from the point of view from someone who is a junior to both
of you in development terms :-), I would have to agree that Ross' take
on this is simpler and more maintainable to the bulk of plone
developers (who have a bit of a dislike for Javascript, as you
mentioned).
You mentioned the problems of flicker, and that it takes more requests
to do it in the manner Ross implemented, but although I can certainly
see it taking more than one request, I don't see how it can take more
than two (one for the javascript, another when the iframe goes to
fetch its content), but please correct me if I am wrong. My first
thought about flicker was, well, why don't you just hide it until its
fully populated and then make it visible, in other words, aren't there
other ways to deal with the flicker (once again, please correct me if
I am wrong).
The platform independent bit, that one certainly might mean that more
should be done in javascript, but perhaps it warrants more discussion.
> now by opinion code looks nice, or at least ok and is also tested. not sure
> how much the coverage is but i tried to cover all the cases i could though
> of,
> i might even bet that its abot 80%.
The code looked nice enough to me :-) I thought replacing "this" with
"self" everywhere was trying too hard to make it all pythony, but it
certainly isn't ugly. Throwing all that out, which was really
unavoidable with the whole move back to the cmsui-way, does have the
rather unfortunate side-effect of losing all the work done on testing.
Seriously, how many people write tests for their javascript? Its just
glue right? :-)
> i believe that getting overlays to work would only need some javascript
> work.
> not that i believe i'm actually sure about it. i dont think i want to merge
> your branch at this point, since i also have to look (in comming week) at
> what
> you've done overlays and then come back to you about it.
When I started with the overlays, I added one function called
overlay(), which was called from the right spot within your object
oriented javascript code. I didn't make it a member of the class,
because there was no reason why it needed access to anything in this
aka self, and it gets glued to links inside the overlay to keep things
inside the overlay, so it had to take the shape of a separate event
handler.
I still have one function called overlay(), although there is a bit
more logic in the click handler, there really is no reason why the
logic behind overlays can't be ported back to the master branch
easily. Right now though, I care about getting something that works
well enough for the project we are on, before I spend time on that,
and because Ross has been putting a lot of time into this, it is
better for me to run with that branch for the moment. It will also
allow a bit more time for discussion.
regards,
Izak
Martin Aspeli
Roché Compaan
> the
> initial goals i had with deco was to create it platform independent. meaning
> that you could easily use deco in any other project with other frameworks.
> this
> would be especially easy with pyramid since plone.tiles is plone
> independant.
> could be even possible with django, since i put all the logic of toolbar
> into
> javascript.
I very much support this as a design goal and I've been checking out
frameworks like AngularJS, Knockout.js, spinejs and few others for
exactly the same reason. It would be a pity if we lose
interoperability and possibly even wider adoption because we move
templating of plone.app.toolbar back to the server.
That said, it has been very difficult and frustrating for me an Izak
to figure out what exactly the state of development is and in a sense
I'm glad a few missteps surfaced these design goals. Our first
impression was that cmsui was completely broken and far from
production ready but we later realised it was in the middle of being
refactored into what is now know as plone.app.toolbar. Nevertheless we
saw it as a good opportunity to take something bleeding edge and make
it production ready by using it in a client project and I think it
will soon be ready. Izak and I talk daily as part of our work on a
project but I've also encouraged him to post updates to the dev list
as often as possible to get feedback and direction and also to give
other developers that were in the dark about plone.app.toolbar & cmsui
and idea of what is going on.
We discussed Rok's approach on master at length this afternoon and
from my point view we should fix the boostrap-overlays branch to adopt
this approach. From what I can tell this shouldn't be too hard to do.
Except for the server side viewlet rendering the iframe, most of the
work done by Izak and Ross is compatible with the client side
rendering of the iframe implemented on master. If Ross has concerns,
particularly the ones that led him to refactor the iframe rendering
code, it would be helpful to hear what they are.
--
Roché Compaan
Upfront Systems http://www.upfrontsystems.co.za
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
Martin Aspeli
That said, it has been very difficult and frustrating for me an Izak
to figure out what exactly the state of development is and in a sense
I'm glad a few missteps surfaced these design goals. Our first
impression was that cmsui was completely broken and far from
production ready but we later realised it was in the middle of being
refactored into what is now know as plone.app.toolbar. Nevertheless we
saw it as a good opportunity to take something bleeding edge and make
it production ready by using it in a client project and I think it
will soon be ready.
Izak and I talk daily as part of our work on a
project but I've also encouraged him to post updates to the dev list
as often as possible to get feedback and direction and also to give
other developers that were in the dark about plone.app.toolbar & cmsui
and idea of what is going on.
We discussed Rok's approach on master at length this afternoon and
from my point view we should fix the boostrap-overlays branch to adopt
this approach. From what I can tell this shouldn't be too hard to do.
Except for the server side viewlet rendering the iframe, most of the
work done by Izak and Ross is compatible with the client side
rendering of the iframe implemented on master. If Ross has concerns,
particularly the ones that led him to refactor the iframe rendering
code, it would be helpful to hear what they are.
Izak Burger
I spent about a day and a half and I reintegrated the ideas of
bootstrap-overlays into a new branch which I named
bootstrap-overlays-v2. Apologies in advance if I'm making too much
branches, but if they are anything like svn branches, at least its
cheap :-)
This branch is based off Rok's code. The toolbar is generated using
javascript. Now that I've worked with both for a bit, there is
definitely a bit more snappiness in the way the javascript
implementation pops up. But development is much slower: debugging
something with pdb is a lot faster than clicking through breakpoints
in firebug.
Initially I did the "port" using the "broad sword" method, which means
I sometimes brought over a little too much and ended up reverted
things again.
I also managed to isolate the various javascript libraries slightly
better. Bootstrap is now loaded ONLY into the iframe, and not into
both as it used to be (this actually caused some interesting problems
with the overlay refusing to open a second time). The toolbar code
itself carries no knowledge of how the overlay works, it fires an
event into the iframe, and everything is handled from there.
The toolbar.js file itself was an interesting candidate. It used to be
in the bundle "default", so that it would load into the main window,
but not into the iframe. I wanted to load the default bundle into the
iframe as well, so that the default plone css is loaded and the
overlays will display correctly, but if I did that, then toolbar.js
would be loaded twice. i therefore placed toolbar.js in its own bundle
and included that into the various skins so it is loaded only into the
main window.
I also preserved Ross' link_target implementation. This meant I had to
drop one of his other DRY fixes, because the relevant class he used
does not surface link_target when you call prepareTabs. I then had to
change the javascript to deal with the extra link_target option and
add it to buttons, but this at least now works the same as the
previous branch: you can force an action to open in the main window
(not an overlay) by setting link_target to _parent.
The unthemed views implementation has been ported. If you glue IUIView
to a view in zcml, it won't be themed.
I'm not completely happy with the css that renders the overlay at
550px high, but for some reason using fixed positioning inside the
iframe does not position it relatively to the viewport as you would
expect, but it seems it positions it relatively to the iframe, in
other words, it behaves like absolute positioning. I think one can
probably just set the height using javascript.
I moved the click handler from the iframe element to the toolbar
element. This is so that clicking on form tabs in the overlay does not
cause the click handler to fire. The downside: if you open a dropdown
there is no way to get it to close again. This is probably not
difficult to fix.
Re javascript: I've certainly learned a lot. Most useful bit of info,
if you are looking for information about an event handler on some dom
object, its here: $(ob).data('events').
My next step, which I really wanted to do today, is to port the
folder_contents views from the old cmsui product. This should probably
become a new product, and the only thing it will do is implement
(probably extend) folder_contents in a way that can be more easily
overlaid, and with enough information so the javascript click handlers
will know when to stay in an overlay and when to drop out, something
that is not currently possible (folder_contents does expose the
content_type using css, but folders aren't the only folderish things,
so that isn't really sufficient).
regards,
Izak
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
garbas
>
> I spent about a day and a half and I reintegrated the ideas of
> bootstrap-overlays into a new branch which I named
> bootstrap-overlays-v2. Apologies in advance if I'm making too much
> branches, but if they are anything like svn branches, at least its
> cheap :-)
>
i've just merged bootstrap-overlays-v2 branch to master.
would be nice if we work together on master (plus short living branches)
> My next step, which I really wanted to do today, is to port the
> folder_contents views from the old cmsui product. This should probably
> become a new product, and the only thing it will do is implement
> (probably extend) folder_contents in a way that can be more easily
> overlaid, and with enough information so the javascript click handlers
> will know when to stay in an overlay and when to drop out, something
> that is not currently possible (folder_contents does expose the
> content_type using css, but folders aren't the only folderish things,
> so that isn't really sufficient).
i was hoping somebody will create a bit nicer bda.finder[1] that we could
re-use.
i think folder_contents is a nice candidate for UI that would be better
handled
in javascript. i already did a prototype of it using Backbone.js, i'll
polish
it over the weekend and we can then compare solutions. in anycase now that
we
have p.a.toolbar in place this things are pluggable.
[1] http://pypi.python.org/pypi/bda.plone.finder
--
View this message in context: http://plone.293351.n2.nabble.com/plone-app-toolbar-and-moving-the-management-ui-into-overlays-tp7350279p7375788.html
Sent from the Core Developers mailing list archive at Nabble.com.
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
garbas
>> independently from p.a.deco. but it uses master branch from p.a.toolbar.
>> about merging your branch to master i'll write in separate email since
>> your changes break p.a.deco.
>>
>>
>> [1] https://github.com/plone/buildout.deco/blob/master/toolbar-only.cfg
>>
>>
>> --
>> Rok Garbas
>>
>
>Talking about testing, I've been working on the selenium2library using
>robotframework for UI testing within Plone [1,2]. This is updating the
>work done at the last Plone Conference Sprints to use the newer Selenium
>2/WebDriver testing framework. Noticing the flurry of activity
>concerning the toolbar/jQuery/Plone UI, I've started to create a
>buildout with robotframework-selenium2library so we can write some
>acceptance tests in support of your work.
>
>I've started with the buildout.cfg that Roche posted yesterday but can
>easily switch to the, above mentioned, toolbar-only.cfg. This would
>probably be better as I can fork (or branch) and share it easier. Any
>thoughts?
i was more thinking in terms of running qunit tests against libraries that
we
use use in plone
and yes that robotframework testing things also look very interesting.
--
View this message in context: http://plone.293351.n2.nabble.com/plone-app-toolbar-and-moving-the-management-ui-into-overlays-tp7350279p7375802.html
Sent from the Core Developers mailing list archive at Nabble.com.
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
David Glick (GW)
+1 for exploring this, backbone.js is a great tool.
----------
David Glick
Web Developer
david...@groundwire.org
206.286.1235x32
The Engagement Party 2012. So much more fun than the wedding reception.
http://www.npoengagementparty.com
Izak Burger
I should have written this email last week already :-) In the mean
time Rok has merged our changes (Roché's and mine).
The last changes was really just to make overlays behave well. Roché
came up with some code that makes folder_contents behave better, by
keeping links that end in @@folder_contents inside the overlay, and
letting others drop out of the overlay. For the most part this works
well, and the toolbar is now quite usable.
The only issue we have at the moment, is that we cannot add content to
folders. In order to do that, you need to drop out of the overlay into
the folder so you can click on the "Add" button. This should however
go away once a suitable folder_contents replacement exist.
Roché also contributed a lot of css fixes, a particular area of
expertise for him, for which I would like to thank him as this is
something my computer-science/engineer-type eye tend to miss (if I can
read it, its good enough for me :-) )
I'll update this thread as we make more changes, something I have to
start doing again right about now.
regards,
Izak
David Glick (GW)
On Mar 20, 2012, at 4:04 AM, Izak Burger wrote:
> Hi all,
>
> I should have written this email last week already :-) In the mean
> time Rok has merged our changes (Roché's and mine).
>
> The last changes was really just to make overlays behave well. Roché
> came up with some code that makes folder_contents behave better, by
> keeping links that end in @@folder_contents inside the overlay, and
> letting others drop out of the overlay. For the most part this works
> well, and the toolbar is now quite usable.
>
> The only issue we have at the moment, is that we cannot add content to
> folders. In order to do that, you need to drop out of the overlay into
> the folder so you can click on the "Add" button. This should however
> go away once a suitable folder_contents replacement exist.
>
> Roché also contributed a lot of css fixes, a particular area of
> expertise for him, for which I would like to thank him as this is
> something my computer-science/engineer-type eye tend to miss (if I can
> read it, its good enough for me :-) )
>
> I'll update this thread as we make more changes, something I have to
> start doing again right about now.
>
Thanks for the update. What's the best way to try out plone.app.toolbar at this point?
----------
David Glick
Web Developer
david...@groundwire.org
206.286.1235x32
The Engagement Party 2012. So much more fun than the wedding reception.
http://www.npoengagementparty.com
------------------------------------------------------------------------------
Roché Compaan
> Am 22.03.2012 um 07:46 schrieb Roché Compaan:
>
>> On Tue, Mar 20, 2012 at 6:09 PM, David Glick (GW)
>> <david...@groundwire.org> wrote:
>>>
>>> Thanks for the update. What's the best way to try out plone.app.toolbar at this point?
>>
>> needs to be updated to point to master since the boostrap-overlays
>> branched have been merged.
>
> The buildout you mention does not work for me. I guess it's missing the newer Products.ResourceRegistries.
>>
>> Additionally, I think we should update the README.txt for
>> plone.app.toolbar with a buildout config that works - currently it
>> points to a non-existent versions.cfg file.
>
> +100
> I really want to test it but it's hard to test stuff that has neither documentation nor a working buildout.
> I got p.a.toolbar to work once with Roks help but I guess too much has changed since then.
Izak reported today that master is somewhat broken compared to the
bootstrap-overlays branch we've been working on. So I have some
testing to do and I'll test it from scratch with a clean buildout and
update the README on master. I'll keep you posted.
--
Roché Compaan
Upfront Systems http://www.upfrontsystems.co.za
------------------------------------------------------------------------------
Rok Garbas
> I really want to test it but it's hard to test stuff that has neither documentation nor a working buildout.
> I got p.a.toolbar to work once with Roks help but I guess too much has changed since then.
>
i've updated README.rst[1] to follow configuration from buildout.deco
toolbar-only.cfg file. basically extending your buildout.cfg to
https://raw.github.com/plone/buildout.deco/master/toolbar-only.cfg should do
the job.
[1] https://github.com/plone/plone.app.toolbar
--
email sent from notmuch.vim plugin
Rok Garbas
> On Fri, Mar 23, 2012 at 1:09 PM, Philip Bauer <ba...@starzel.de> wrote:
> > Am 22.03.2012 um 07:46 schrieb Roché Compaan:
> >
> >> On Tue, Mar 20, 2012 at 6:09 PM, David Glick (GW)
> >> <david...@groundwire.org> wrote:
> >>>
> >>> Thanks for the update. What's the best way to try out plone.app.toolbar at this point?
> >>
> >> There was a buildout config I attached earlier in this thread. It
> >> needs to be updated to point to master since the boostrap-overlays
> >> branched have been merged.
> >
> > The buildout you mention does not work for me. I guess it's missing the newer Products.ResourceRegistries.
> >>
> >> Additionally, I think we should update the README.txt for
> >> plone.app.toolbar with a buildout config that works - currently it
> >> points to a non-existent versions.cfg file.
> >
> > +100
> > I really want to test it but it's hard to test stuff that has neither documentation nor a working buildout.
> > I got p.a.toolbar to work once with Roks help but I guess too much has changed since then.
>
> Izak reported today that master is somewhat broken compared to the
> bootstrap-overlays branch we've been working on. So I have some
> testing to do and I'll test it from scratch with a clean buildout and
> update the README on master. I'll keep you posted.
>
i was just about to write email about it. i did some changes and remove quite
some code and preserve functionality, but i've had to stop working on it. in
all the hurry i was into i've pushed to github, which proabably left master in
not working state. sorry about that.
i plan to work on toolbar and overlays tonight to get this fixed.
can you meanwhile continue working on "bootstrap-overlays-v2" and i'll make
sure that everything gets merged into master. once master is functional i'll
send email to this thread.
Roché Compaan
Thanks for the update Rok. We weren't clear on where exactly you're
heading with the changes on master and where to continue with
development. Maybe you can just give as a brief overview of what
changes your are planning?
Maybe we should stick to working on feature branches and merging it to
master so that developers that want to try it out get a better sense
of progress, rather than doing a buildout against a broken master.
Alternatively the installation section in the README should point to a
branch that isn't in the middle of being refactored.