Search: concept

comment : There is not much about the changes in database schema and how to limit extensions broken by the removing of space concept.

A folder or a nested documents concept seem more intuitive.

. (-) High profile target Many people will write specialized bots to get past it Proof of concept This is just a demo of how to directly use the NO CAPTCHA reCAPTCHA service inside XWiki, without any integration work done.

. (-) High profile target * Many people will write specialized bots to get past it ))) (% class="col-md-3" %) ((( [[image:http://4.bp.blogspot.com/-wt7yljKcU_8/VH5MJTUCBOI/AAAAAAAAACw/WKqE3ixUUdw/s1600/Recaptcha_anchor%402x.gif]] [[image:http://4.bp.blogspot.com/-sLrMDmf4gOc/VH5MJRg7VnI/AAAAAAAAACU/svXWqwOpyds/s1600/CAPTCHA.png]] ))) (% class="clearfloats" %) ((( ))) == Proof of concept == This is just a demo of how to directly use the NO CAPTCHA reCAPTCHA service inside XWiki, without any integration work done.

comment : Note that this is what was done before and what I explicitly removed in the past on the basis that: * Hard to fully make it your own (you'll need to remove all its xobjects to be clean - WTF effect if you don't and someone edits in objects mode) * Modifying it was loosing the dashboard (hence the move of that dashboard as a separate app) * It allowed to more easily implement the concept of deciding what your home page would be by simply including the page you wanted to show as your home page

profile : * Java proficiency * Familiar with unit testing concepts and best practices * Familiar with functional testing concepts and best practices ** Experience with Selenium and the [[Page Objects>>url:https://code.google.com/p/selenium/wiki/PageObjects]] pattern is preferred * Familiar with web technologies: HTML/CSS/JavaScript * Experience in (unit/functional) testing a previous open source project is a big plus * Willingness to learn and to improve both him/herself and the project

We mostly need two entry point (et probably two corresponding modules): a java side manager, a script service 1.0 aka "new PageReference APIs without stuff we don't agree yet" The scope of this version is to provide new page oriented API for scripts and Java components but not concentrate on supporting page concept in HQL requests. References New typed EntityReferences We need new entity types and corresponding reference helpers: PageReference (EntityType.PAGE) PageObjectReference (EntityType.PAGE_OBJECT) PageObjectPropertyReference (EntityType.PAGE_OBJECT_PROPERTY) PageClassPropertyReference (EntityType.PAGE_CLASS_PROPERTY) PageAttachmentReference (EntityType.PAGE_ATTACHMENT) Model script service Add new helpers for the new types and deprecate the old ones.

Java Like said in the General section the plan is not to write The New Model™ but just to provide to the already existing APIs an easy Page concept oriented access. new com.xpn.page.XWikiPage class used by hibernate hbm methods for all the fields of the database lazy loaded XWikiPage#getXWikiDocument(XWikiContext) helper to access other stuff like object/attachments/etc. and make easier to reuse and adapt existing code (extending XWikiDocument would make XWikiPage directly expose methods that are not following page concept or that we would want to behave differently for this name).

We mostly need two entry point (et probably two corresponding modules): a java side manager, a script service = 1.0 aka "new PageReference APIs without stuff we don't agree yet" = The scope of this version is to provide new page oriented API for scripts and Java components but not concentrate on supporting page concept in HQL requests. == References == === New typed EntityReferences === We need new entity types and corresponding reference helpers: * PageReference (EntityType.PAGE) * PageObjectReference (EntityType.PAGE_OBJECT) * PageObjectPropertyReference (EntityType.PAGE_OBJECT_PROPERTY) * PageClassPropertyReference (EntityType.PAGE_CLASS_PROPERTY) * PageAttachmentReference (EntityType.PAGE_ATTACHMENT) === Model script service === Add new helpers for the new types and deprecate the old ones. === New reference syntax === * use '/' as separator instead of '.' * same separator for all types except for wiki which would remain ':' (to differentiate between Page and Wiki parent) * use '.' as current page and '..' as parent page * the escaping character stay '\' * we also need to introduce syntax for the locale which we still don't have in the current syntax partly because it's very hard to introduce without breaking anything.

We should not need to introduce new SOLR types for PAGE children (same as database here again). == Java == Like said in the [[General section>>||anchor="HGeneral"]] the plan is not to write The New Model™ but just to provide to the already existing APIs an easy Page concept oriented access. * new com.xpn.page.XWikiPage class used by hibernate hbm ** methods for all the fields of the [[database>>||anchor="HDatabase"]] ** lazy loaded XWikiPage#getXWikiDocument(XWikiContext) helper to access other stuff like object/attachments/etc. and make easier to reuse and adapt existing code (extending XWikiDocument would make XWikiPage directly expose methods that are not following page concept or that we would want to behave differently for this name).

The initial prototype is promising but wil need work to allow concurrent access and faster handling of big volumes of data. Currently the concept is ongoing translation. Reimport of the main language (english) file can be done regularly.

Once it is loaded on launchpad.net there is a quite extensively developed translation application. The concept seems to work by application version. We need to verity if this is the way we want it to work.

The initial prototype is promising but wil need work to allow concurrent access and faster handling of big volumes of data. Currently the concept is ongoing translation. Reimport of the main language (english) file can be done regularly.

Once it is loaded on launchpad.net there is a quite extensively developed translation application. The concept seems to work by application version. We need to verity if this is the way we want it to work.

{{usecase}} The user needs to understand the concept of wiki/space/page (see the [[discussion>>http://markmail.org/message/7y62ewmo2ltdeomq]]) {{/usecase}} {{usecase}} The user needs to be encouraged to take ownership of his wiki {{/usecase}} {{usecase}} The user needs to be able to easily replace the home page with his content {{/usecase}} {{usecase}} (optional) The user needs to be able to easily set an application as his homepage (i.e. use a dashboard, user directory, etc.; mostly the case for subwikis) {{/usecase}} {{usecase}} The user needs to be able to discover the wiki's content (navigation) {{/usecase}} {{usecase}} Flavors need to be able to easily set/replace the homepage with the one that best suits their intent/focus: public website - dynamic content, knowledge base - navigation, groupware - wiki status, etc {{/usecase}}

a) Improve the welcome message displayed by Main.Welcome to focus on wiki concepts. Maybe on the lines of what we have already discussed in the past This hopefully fixes UC1 b) Fix welcome gadget editing problems by either simply adding an edit action/button on that gadget or by going the long way with c) below.

a) Improve the welcome message displayed by Main.Welcome to focus on wiki concepts. Maybe on the lines of what we have [[already discussed in the past>>http://design.xwiki.org/xwiki/bin/view/Improvements/HomepageContent]] * This hopefully fixes UC1 b) Fix [[welcome gadget editing problems>>http://jira.xwiki.org/browse/XE-1389]] by either simply adding an edit action/button on that gadget or by going the long way with c) below

Risks / Side Effects Side Benefits 11 ● New product AND new UI for XWiki Risks 12 ● Being spread thin ● Tackling too many projects at the same time ● Technical difficulties in making a product with multiple targets Next steps Next Steps 14 ● Research Project -> get funding (done in May 2023) ● Prototyping (proof of concept) ● Architecture (layout the technical vision and architecture of the components) ● MVP (Simple Wiki, with 2 backends) ● Build Community / First offers ● Additional backends Questions ?