Re: [xwiki-users] struggling to understand panels expanding initial state
Hi Lockie! On 3/8/11 1:31 AM, Lockie wrote: > Ricardo Rodríguez wrote: >> #if(!$expanded) >> #set($expanded = 'collapsed') >> #end >> > Thanks I found this helpful. It means I don't have to have javascript > extensions collapsing the panels, slowing down load times. But as Raluca stated in her previous message, this causes the panels to keep collapsed because this value prevents the cookie to be created. I'm afraid I'm still lost with this issue: I don't understand yet why setting $expanded = 'collapsed' instead of reading its value from a cookie prevents cookies function. Please, Lockie, how to you get a collapsed panel at page loading time being later on controlled by a cookie? I mean, panel A appears collapsed when you access the site for the first time. From this moment onwards, a cookie will remember the preferences of each visitor. Here it is the example that is making me nuts: http://pescaderias.org It is a simple portal still in progress. I want that all four menus on the right will appear collapsed the first time a visitor/users access the site. And that the stated of each panel will be stored in a cookie for subsequent visits. #set($expanded = 'collapsed') allows me to show them collapsed, but prevents cookies function. In fact cookies are never created. I think I understood Raluca's explanation in the her previous message in this same thread, but I'm still not able to find a solution for this issue. Thanks! Ricardo > - > > Lockie > -- > View this message in context: > http://xwiki.475771.n2.nabble.com/struggling-to-understand-panels-expanding-initial-state-tp6095465p6099685.html > Sent from the XWiki- Users mailing list archive at Nabble.com. > ___ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users -- Ricardo Rodríguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] struggling to understand panels expanding initial state
Thanks Raluca!
Please, see below.
On 3/7/11 7:51 AM, Raluca Stavro wrote:
> Hello,
>
> On Mon, Mar 7, 2011 at 12:39 AM, Ricardo Rodriguez [eBioTIC.]
> mailto:ricardo.rodrig...@ebiotic.net>>
> wrote:
>
> Hi all!
>
> I'm still struggling to understand how expanded/collapsed state of
> panels do work.
>
> I'm currently using a 2.4.30451 XE/XEM installation.
>
> Looking for macros controlling this state in macros.vm, I see:
>
> ***
> #macro(panelheader $title)
> #set($cookieName = "${context.user.replaceAll(':','')}_${panel}")
> #set($expanded = $xwiki.getUserPreferenceFromCookie($cookieName))
> #if(!$expanded)
> #set($expanded = 'expanded')
> #end
> ## Note: We pass the Panel name as an HTML class attribute so that
> it's
> possible to style
> ## the Panels selectively using CSS.
> #set ($specialClassAttribute = "")
> #if ($paneldoc && $paneldoc != "")
> #set ($specialClassAttribute =
> $util.convertToAlphaNumeric($paneldoc.name ))
> #end
>
> onclick="togglePanelVisibility(this.parentNode,
> '${cookieName}');">$title
>
> #end
> ***
>
> This macro creates an expanded panel. By clicking the panel title, the
> system creates a cookie that stores her current state.
>
> But if I modify this macro and says...
>
> #if(!$expanded)
> #set($expanded = 'collapsed')
> #end
>
> No macro is created and panels are always collapsed when loaded and
> after relaoding.
>
>
> That is because 'collapsed' is used as a class name for the panel dom
> element and there is also a CSS rule which says that panels with
> 'collapsed' class name are being displayed as collapsed.
> So, the default logic is like this:
>
> 1) take the $expanded value from a cookie
> 2) set the panel dom element class name as being the value of $expanded
> 3) on loading the page, with the help of CSS, display the panel as
> being 'collapsed' or 'expanded', depending on the value of $expanded
>
> And in your case, this is the logic:
>
> 1) set the value of $expanded as being 'collapsed'
> 2) set the panel dom element class name as being the value of
> $expanded (which is 'collapsed')
> 3) on loading the page, with the help of CSS, display the panel as
> being 'collapsed', this being the value of $expanded
>
> I hope that this helps you understand the logic behind 'collapsed' and
> 'expanded' panels.
>
> Raluca.
Yes, it helps. Thus, to control the initial state of a panel (collapsed
or expanded) the first time I load a page (no cookie has been set for
that panel) what I need is to create a cookie with the desired value.
Please, is this correct? If yes, could you point me to the best way of
creating that cookie at loading time?
Thanks!!!
>
> Please, could you me understand why?
>
> Thank you so much!!!
>
> Ricardo
>
> --
> Ricardo Rodríguez
> CTO
> eBioTIC.
> Life Sciences, Data Modeling and Information Management Systems
>
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
>
--
Ricardo Rodríguez
CTO
eBioTIC.
Life Sciences, Data Modeling and Information Management Systems
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] problem displaying empty list as property in class sheet velocity script
On 03/11/2011 10:43 PM, Mark Wallace wrote:
> I am having a velocity script problem with a class sheet when I try to
> display an empty list on an object.
>
> My goal is for the class sheet to render class properties that start
> with a "_" as hot-links, and those that don't to just be rendered as text.
>
>
> The class sheet is for "PersonClass", and looks like this:
>
> {{velocity}}
> #set ($obj = $doc.getObject('XWiki.PersonClass'))
> #set($class = $obj.xWikiClass)
> #foreach($prop in $class.properties)
> ; $prop.prettyName
> #set ($propName = $prop.getName())
> #set ($propVal = $obj.get($propName) )
> #if ($propName.startsWith("_"))
> : $propVal (why does this one not show?)
> : [[$propVal>>$propVal]] (but this one does show?)
> #else
> : $doc.display($prop.getName())
> #end
> #end
> {{/velocity}}
>
>
> The PersonClass has two properties:
>
> (1) name (a string)
>
> (2) _knows (a DatabaseList with multiple select and XWiki Class Name of
> XWiki.PersonClass)
>
>
> I create an object using this class, with "name" set to "C S Lewis" and
> with no selection for the _knows field (empty list).
>
> The problem is, the velocity line:
>
> : $propVal (why does this one not show?)
>
> works properly... not displaying anything for property _knows (empty
> list), but the line:
>
> : [[$propVal>>$propVal]] (but this one does show?)
The link syntax is different. If $propVal is the empty string, then the
link becomes:
[[>>]]
If you look at the specification of the syntax:
http://platform.xwiki.org/xwiki/bin/Main/XWikiSyntax#HXWikiSyntax2.0LinkSpecification
you'll see that the first part is the label, which is optional, and, if
missing, falls back on the name of the target document. So something
will appear there.
The second part is the name of the target document, which is resolved as
a reference relative to the current document. "Resolved" means that any
missing part of the reference, "wiki", "space" or "document", is
replaced with a default from "current wiki", "current space", "current
document". So, in fact your link translates to:
[[xwiki:Space.C S Lewis]] which prints the name of the document, C S Lewis.
You're not the first user surprised by this behavior, maybe we should
change it?
Anyway, a quick fix would be:
: #if ("$!propVal" != '')[[$propVal>>$propVal]]#end
> which is the line I really want to use in the class sheet, because it
> creates the hot links, shows the value from the previous property as a
> hot link. I.e. it looks like this:
>
> name
> C S Lewis
>
> _knows
> (why does this one not show?)
> C S Lewis (but this one does show?)
>
>
> Not what I wanted. Why does it do this? How can I get empty lists to
> show no page links, but lists with one or more items to display them as
> a bunch of hot links?
>
> Thanks,
>-Mark
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Migrating XE from 2.4.3 to 2.7.1 and 3.0
On 03/11/2011 11:41 PM, Dennis Rasey wrote: > On 03/11/2011 11:56 AM, Sergiu Dumitriu wrote: >> On 03/11/2011 08:03 PM, Ramon Gomes Brandão - SERINT wrote: >>> Hi XWiki Team, >>> >>> Sorry if this is a recurring thread, but can't find more details on >>> it. I'm using XE 2.4.30451 in production enviromnent on my company, >>> and due to the numerous new functionalities of the new XWiki >>> versions, I'm planning to migrate to 2.7.1, and after to 3.0. >>> >>> My question is: can I upgrade it as easy as just replacing the >>> entire old war file with the new one (of course, with the tunings >>> I've made on it, such as WYSIWYG macros, footnotes etc, setting the >>> schema migration flag on xwiki.cfg? Won't I lose any of my >>> documents, pages, attachments, comments etc at all? Of course I'll >>> test it first, outside the production, but I would like to gather >>> as much information I can to plan the entire migration process. We >>> have a very large set of pages already on the wiki, and I wouldn't >>> like to face big problems :-) >> >> Normally, yes. All the documents are in the database, so all that's >> important in the war is: - the xwiki.cfg and xwiki.properties >> configuration files - the database connector jar - any other jars you >> added, or files you manually changed >> >> Then you should import some of the documents from the new XAR, since >> many features come inside wiki pages. This is a bit more difficult, >> since you don't want to override changed configuration documents >> (like XWikiAdminGroup or XWikiPreferences), or documents you have >> changed (like Main.WebHome or Panels.QuickLinks). > > If I do not import some documents (like XWikiAdminGroup or > XWikiPreferences), could I be missing out on changes that are contained > in the newer versions of those documents? XWikiAdminGroup no, since it's just a data container, the UI is generated by a sheet, XWiki.XWikiGroupSheet, which you should import. XWikiPreferences is a bit more problematic. It contains both data (the configuration) and metadata (the definition of the XWiki.XWikiPreferences class). The UI is again defined in a sheet, XWiki.AdminSheet, which you should import, so the improved administration (in 3.0) will be included, but some of the fields will be missing since they are defined in XWiki.XWikiPreferences itself. This is a wrong design in the software, but it will take some time to improve. > >> What can break things is changed APIs or behavior changes caused by >> bugfixing (which means that some code was exploiting a bug). For >> example, you might get deprecation warnings in the server logs. If >> you properly upgrade the entire war, and you import the new xar, >> there should be no headaches. >> >> More detailed instructions at: >> >> http://platform.xwiki.org/xwiki/bin/AdminGuide/Installation#HUpgradinganXWikiInstallation >> -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
