Hi devs,
I've made a proposal on rights improvements at
https://forum.xwiki.org/t/ux-rights-improvements/107
Haven't received much feedback on it so I'm cross posting it here in case
you've missed it.
Thanks,
Caty
Hi, devs,
While handling https://jira.xwiki.org/browse/XWIKI-14157 (Display the
default and inherited values in the Administration), I`m trying to come up
with a solution that is applicable more generally and avoid having to
manually patch just the problem at hand.
We could think of this as a 2 piece problem:
1) getting or specifying the default value (or maybe it's more correct to
say default display value?)
2) displaying a form field and handling the default value (view/edit modes)
1) would be much simpler if we only had to handle a flat level class and
its objects, but, for XWikiPreferences, we also have the
"space<space<wiki<xwiki.cfg" inheritance to consider. This inheritance is
done through the use of various ConfigurationSource implementations that
delegate one to another.
The problem with ConfigurationSource is that, through its use of
getPreference(preferenceName, defaultValue), we end up in proliferating
default values throughout the code, each time we just want the value of
that preference, resulting in a big mess and not knowing what is the
default value for that preference and where it is set.
I was thinking of adding some:
* <T> T getPropertyDefault(String name) method which would allow a
ConfigurationSource to handle by itself the retrieval of the default value
for a property and a
* <T> T getPropertyOrDefault(String name) convenience method for callers to
fallback on the internally-determined default value, without caring what it
actually is.
As an example, this would be useful when calling
$xwiki.getXWikiPreference(...) since we don`t have to specify the default
value in the caller, but it will be retrieved by performing the fallbacks
mechanism space<space<...<wiki<xwiki.cfg.
Still for 1) but for ConfigurableClass sections that rely on a simple
configuration class (or any other form that relies on properties defined by
a class), one idea would be to add a "defaultValue" meta-property (with
associated getter/setter in PropertyClass) in the class that allows
specifying the default value of a property when defining it. This would
allow a displayer to have the default value and properly display it,
instead of weird "---" stuff we do now and all kinds of *fake* values, just
so that the user can select them.
(We may also need a "defaultPrettyValue" or "defaultDisplayValue", with
associated getter/setter, for things like DBList).
Reminder: We already have a "defaultValue" meta-property for BooleanClass,
so it looks like we had the idea before, just did not take it all the way.
So XWikiPreferences goes more into the "specifying the default value at
display time" workflow, IMO (because we would have to provide the default
value that is retrieved from a "special" mechanism, i.e.
$xwiki.getXWikiPreference(...))... and we should use the "getting the
default value" (from the class property's "defaultValue) as the default
behavior, for simple objects of simple classes.
Finally, for 2), I`m thinking that we might need a way to also pass the
default value to a display() call, overwriting anything else, in order to
support custom fields that get their defaults from external sources or
other mechanisms that don`t involve the XClass and the "defaultValue"
defined there (like XWikiPreferences does, for example, or other custom
stuff).
This also introduces the problem that not everybody might want a default
value proposed in their form for a certain element, so we should also be
able to specify, at display time, if the default value should be proposed
or not.
These optional additions to the display method ("defaultValue",
"defaultDisplayValue", "showDefault", etc.), including the existing ones
("prefix", "wrappingSyntaxId", etc.) should probably be done with a new
signature that also takes a map of parameters.
The aim is to rely as much as possible on $doc.display(property,
parameters) when creating forms in XWiki, while also encapsulating the
default value to the location responsible for it, and not to the caller.
WDYT?
Thanks,
Eduard
Hi, so I'd like to request for a Github repository for my RedPen integration
project.
As of now, I'd like to name the repository application-document-checker
(yeah it's two words instead of one but I feel it is necessary to capture
the full meaning of this application)
As for description, I think it is enough for now to describe it as a
proofreading tool to ensure that the quality standards of a Wiki document is
met.
My GitHub name is laskjk (It is an old username made a year back and I'd
like to keep the history of my commits in one account)
As of now this is what I need. I'll request for more hosting tools at a
later date, when I am nearer to producing a working application.
Thank you for your help!
--
View this message in context: http://xwiki.475771.n2.nabble.com/Contrib-RedPen-Integration-Request-for-pr…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
I'm getting closer to finish with the hard work around new platform
flavor which is going to replace XE.
Need to decide what user will see in the Flavor picker when installed XWiki now.
As a reminder we decided that this would be a generic flavor, not tied
to any specific use case (so forget about "Knwonledge Base Flavor"
:)).
Here is a few ideas gathered in previous mails:
* "XWiki Flavor"
* "Default XWiki Flavor"
* "Generic XWiki Flavor"
* "Base XWiki Flavor"
"Generic" is probably a way too technical term.
"Base" would be misleading IMO since it's not really a base flavor.
Its primary goal is not to be used as a dependency (of course it's
fine to have it as dependency if you just want to add pre installed
extensions to the default flavor). It's a -1 for me.
Frankly I would simply go for "XWiki Flavor". I know, it's not going
to be the only flavor for XWiki but it's obvious when you actually see
severals of those in the picker anyway and I find it nicer than
"Default XWiki Flavor" which basically means the same thing since the
XWiki core project does not plan to provide any other flavor. I'm also
fine with "Default XWiki Favor" if others think it's a better name.
WDYT ?
--
Thomas Mortagne
Hi all, this is another weekly update with regards to the work on the RedPen
extension.
I've more or less created a component + scriptservice that helps to validate
an input string of text. How
I envision this to work is that an Event Listener would obtain the context
of the document when the
user saves the page, parse it using the syntax rendering component to plain
text, then run it through the
component I've made. Hence, the next week would be dedicated to writing the
event listener.
I have still not designed how I am going to take in the user's validation
settings, hence I have an incomplete Java class and will work on it after
writing the event listener
With that in mind, I think I should request a repository on xwiki-contrib,
since I already have some starting code available locally. May I know what
are the required steps I need to achieve that?
Next, I understand that there are three ways that one can write an event
listener, either using an XWiki Component in a jar, a Wiki Component or
using Groovy. I am currently considering using Groovy to create the Event
Listener directly within a wiki page. Any thoughts on that?
Lastly, I am unsure of the report format and details to submit as part of
the GSOC programme. Can I get some clarifications with regards to it?
Thanks.
--
View this message in context: http://xwiki.475771.n2.nabble.com/Update-2-RedPen-Integration-tp7604136.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
With https://jira.xwiki.org/browse/XE-1527 (http://markmail.org/message/t7khe7ufdtlsf5gl) we’ve removed the WebDAV feature by default in XE.
I’d like to propose to go one step further and consider the webdav feature as non-core and move it outside of the xwiki github organization and into xwiki-contrib. I’d also propose that the XWiki Core Dev Team stops supporting it.
Rationale:
* We haven’t touched it in a long long time
* It’s not a feature requested by our users anymore
* If any contributor is interested in working on it one day, it’s simpler in xwiki-contrib and it can be released independently of XWiki
Here’s my +1
Please cast your vote
Thanks
-Vincent
Could be interesting…
Thanks
-Vincent
> Begin forwarded message:
>
> From: YourKit <info(a)yourkit.com>
> Subject: New product from YourKit: monitor CI servers, build tools and tests
> Date: 12 June 2017 at 09:48:07 GMT+2
> To: vincent(a)massol.net
>
> Greetings,
>
> YourKit is proud to announce an early access to the new product codenamed "ProjectX":
> monitoring and profiling solution for continuous integration servers, build tools
> and testing frameworks.
>
> With ProjectX you can monitor in runtime how your software project
> builds (Ant, Gradle, Maven) and tests (JUnit, TestNG).
>
> No other tool will such comprehensively tell you what your software build
> consists from or give you insight how to optimize it.
>
> Moreover, a historical data of monitored builds is remembered to immediately detect
> any build and test performance regressions, which may indicate a problem or a regression
> in your software project itself.
>
> In particular, you may think that ProjectX automatically makes your existing unit tests
> performance tests too.
>
> You can monitor builds under continuous integration servers (Jenkins, Hudson, TeamCity),
> from within your IDE in development (Eclipse, IntelliJ IDEA, NetBeans) or even standalone.
>
> Find more detail and download at
> https://www.yourkit.com/projectx/
>
> The first build which is now available provides basic functionality,
> but is valuable enough to give it a try.
>
> More features and improvements to come, stay tuned!
>
> Kindest regards,
> YourKit Team
> ____________________________________________________________
> If you would not like to receive any more information about
> YourKit products, simply send an email to info(a)yourkit.com
> with the subject line "unsubscribe".
Hello all,
It's been 2 days that I am stuck in a stupid error.
I have a "add glossary" button in my application, and when I click that
button, the browser gives me the error: "This page isn’t working, 127.0.0.1
redirected you too many times."
Now this is a redirect loop. And it's caused by the statement
$response.sendRedirect($xwiki.getURL($newGlossaryReference, 'inline',
"$!{request.queryString}&title=${escapetool.url($glossaryItem)}")) in my
code I guess. I am not able to figure out why this is looping even if there
is no loop. I have tried certain things but there is no progress.
Moreover, my title bar appear like this:
http://127.0.0.1:8080/xwiki/bin/inline/Glossary/Hello?parent=Glossary.WebHo…
Here is my complete code: https://pastebin.com/p95DeHMg
Could someone please take some time and help me out?
IRC:sarthakg
Thanks
Sarthak Gupta