Hi devs,
This is a thread to discuss what kind of title behavior we want in the future. I've listed some topics I consider open below. Could you give me your opinion about them?
1) Should we force titles to be mandatory by default
2) Should we merge page names and titles in the UI (ie only expose titles and compute page names based on it)
3) Do we want titles to be generated from content if the title is empty or not. If 1) is agreed then there'll always be a title set so this is probably not needed
4) Should we allow wiki syntax in the title field and make that field a textarea rather than a single line string (to allow scripts to generate titles, this is useful for applications for example). Note that currently the title field can only contain velocity and no wiki syntax AFAIK.
Any other topic to discuss related to titles?
Thanks
-Vincent
Hello,
I want to download the source code in order to build from source.I cant
find a zip file which contains the source.Can someone help me?
Thank you!:D
Hi,
I was working on the XWiki Mobile skins initial iterations of layouts and themes and would like to discuss further on this topic.These are some of the UI views:
http://www.globaldelight.com/XWiki/xwiki-layouts.jpg [Overall feel and look]
http://www.globaldelight.com/XWiki/activity-page.jpg [Activity Page]
http://www.globaldelight.com/XWiki/edit-page.jpg [Edit Page]
http://www.globaldelight.com/XWiki/profile-page.jpg [Profile Page]
I am working further on creating more detailed versions and also flowcharts for the views.
On reading the previous threads I wanted to dig in on Development point of view. I thought of 2 options for the scope of this project and its purpose.
1. Making a browser based mobile skin only by using HTML5 + CSS + JS , velocity templates and fetching the data from REST or XML-RPC. The data can be also displayed by using Ajax making it a good web-app. But this does not allow the use of native capabilities like camera or notification as it resides on the browser.
2. The use of web-technologies for making cross-platform application with JS touch framework and porting framework.
The application needs to use the phones native features such as Camera API, Notification(Vibrate) , Geolocation, File Storage and much more which are not possible via simply an web-application so requires a porting framework.
Either PhoneGap or Appcelerator Titanium will be good but i have been following both and I want to point out a few things.
Advantages of PhoneGap
-MIT licence
-Easier testing in browser /simulator
-Support for iOS , Android, Symbiam, PalmOS
Advantages of Titanium
-Easy to get native looking app , native UI component
-Better performance
-can be extended to add native feature
Developing on PhoneGap or Titanium is not an ideal form considering XWiki is written in Java but solves the purpose of making it mobile compatible.
These allows the app to be natively packaged for different platforms like iOS , Android or Symbian. This way the app resides on the phone and only minimum data transfer is required. This would really enable to access XWiki on mobile devices in an appropriate way. The main focus is to access the main XWiki features. I am still working on fetching data using REST on the above porting framework , would be great if i could get more help on this.
Hope my ideas and opinions would be helpful. I would really appreciate comments and remarks towards this.
Regards,
Avinash
Hi Everyone!
I'm a third year student from Mexico, the proyect AJAX form Editor sounds
pretty good to me, i have a PHP5, XHTML/CSS, JavaScript, Jquery,Python and
some ruby background. i did some stuff working with Drupal (plugin
managment, edit views, etc.) this as part of my social service, no big deal
and currently developing something call "interactive book" as part of a
academic final proyect, here i help to a PhD student to implement some
interactive functionalities to his work (using Jquery mostly ).
I found excited this AJAX form editor proyect, 'cause this could be a pretty
nice oportunity to implement/work with AJAX so, i would like to know what
you guys expect regarding this?...
I was cheking out the within minutes page, and i wonder if the "form editor"
just gone be an extension of the "whitin minutes proyect". Or what is the
relation between them.
Cheers! :)
--
Omar R. López Orendain
Hi devs,
since I fail in all the ways to get a dashboard to be editable when
editing it after creation from a template, I would like to know what you
think of the next idea:
We add a field to the TemplateProvider to specify what should be the
action on creation from that template: "save & view", "save & edit", or
"edit".
Let me explain what first option would mean and then you'll figure out
the other ones. When you have a template provider with "save and view"
action on creation the following will happen:
1. click the add button
2. choose a template & fill in the page & space name
3. click create
4. the document is created and saved, and the user is being shown the
document in view mode.
The current implementation is "edit", which means that at point 4 in the
list above no document is saved, the user is being shown the new
document is edit mode, and until he hits save the document is not saved.
I think it's a nice to have feature, since for other templates it might
make sense that the document is, actually, created (and saved). Since a
document created from a template already has content, it has meaning and
data.
** The only major drawback** I see with this is that, looking at the
create form, the user will not know what will happen when he clicks
"Create", since it will vary according to his choice of template. We
might fix this by adding this information under the template name in the
list of templates in this form.
What do you think about this? is it a nice feature to have?
Thanks,
Anca
Hi all,
I've got some suggestions that the current way of editing the dashboard
is not really intuitive (Edit -> Inline Form), and mainly because users
wouldn't necessarily look under "Edit" for a method to change the
dashboard. Also, other users that I've observed, forgot that they need
to go in some edit mode before changing things.
I also agree that without documentation no user would figure out that
editing a dashboard is under Edit -> Inline Form. While editing will
still remain "in inline mode", from the technical pov, we need to
provide a easier way for users to discover this.
Let's look at the following options:
1/ Add a "Customize" menu entry under edit, in the page menu, as
proposed in the mockups from Cati, a long time ago:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/GadgetsDashboard .
2/ Add a "Customize this dashboard" button in the dashboard in view
mode, in the top right corner, something like
http://dev.xwiki.org/xwiki/bin/download/Design/GadgetIntegration/oldDashboa… but styled better to integrate with the current dashboard.
3/ Define and implement a mechanism to allow the inline form edit to be
triggered for a document without that document having to include a
document which has an object in it. E.g. as Vincent proposed at one
point, trigger inline mode when an object is present in the current
document.
I should note that solutions 1 and 3 still assume that the user will go
to "Edit" to try to customize the dashboard, which can also be
problematic (I cannot figure it out for sure right now, we need fresh
users or proper UX expertise which I don't have).
WDYT?
Thanks,
Anca
Hi, Everyone,
I am going to apply for student developer in GSoC 2011 and am interested
in one of proposed XWiki projects, XEclipse "RESTification".
Currently I am a fourth year Ph.D. student in the department of Computer
Science, University of Georgia, USA. My research focuses on
Simulation/Modelling and Web services, and applies them to facilitate
bioinformatics research.
My strengths are the following:
(1). 6-year of Java programming experience including both desktop and
web development and able to perform full lifecyle software development.
(2). developed a SOAP Web service management system using Eclipse RCP
and SWT
(3). developed REST-ful Web services and integrated SOAP Web services
from other collaborators (in German and Japan) to implement integrated
scientific workflow following Web 2.0 standards
After reading through the descriptions of proposed projects, XEclipse
"RESTification" is of great interest to me. This project involves
communication via SOAP and REST-ful Web services and is developed in
Eclipse SWT platform, therefore, I might be a potential match for this
project based on the skill set.
I have several questions regarding the requirement:
(1) what is target development platform?
The current XEclipse requires Eclipse Ganymede 3.4 and the most
recent release is Eclipse 3.6 and 3.7. Is there any plan to support them?
(2) What is the current status of XWiki communication layer?
From what I understand, SOAP + XML play a main role in the current
system. Now XWiki is turning to REST eventually.
I read some discussions on Mar 11 2011 about REST API in dev mail
list, which mentioned that REST API is not there yet. Does this mean
that the whole REST communication layer is not available yet?
(3) What extent of RESTification we are going to achieve for XEclipse?
This is closely related to question (2). If REST API is available,
the XEclipse RESTification will only need to construct the REST-ful
request (i.e., @GET /rest/{space}/{page}) and parse result from server.
If not, more work might be involved.
Best regards
Jun Han
--
Jun Han
Computer Science Department,
the University of Georgia
http://sites.google.com/site/junhan37/
Hi,
I am Shweta Agrawal, final year computer science student at IIT Roorkee,
India. I want to apply for GSoC this year and am interested in working on
Photo Album Application. I have four year experience in web development and
have good understanding of HTML, CSS, Php, python and Javascript. I have
worked on creating user interfaces for a couple of websites and developed
applications like online music player (similar to grooveshark), online
notice board etc for my Institute's intranet.
As far as I understand the project, it's aimed at developing an application
where users can
- upload the photos (one by one or zip files or folders) with
information like date, caption, location etc.- this info can be extracted by
reading exif information. *additional* - multiple file selection and
upload, drag and drop functionality (supported by HTML 5 compliant
browsers). ** *doubt* that do we intend to create a default album for all
the images uploaded/attached by user on any of the pages i.e. not only the
images that are uploaded for some album. It will provide user an easy way to
manipulate and browse through all uploaded image files.
- create albums and add information like title, caption, description and
location. *doubt* - will there be any limit on maximum number of
photographs in an album?
- browse through the uploaded photographs (available in browsers not
having javascript - It can be done using css3).
- view as thumbnails and slideshow (with adjustable timer and with
manual browsing).
- migration tool from the old version photo albums. *doubt* - what does
old version photo albums refer to?
- ability to tag and associate comments with attachments. *doubt* - does
attachments here refers to image files only or any type of files.
I have browsed through the code of older photo album application. I need
guidance that is how should I start working on this application? I am
thinking about starting with uploading part.
Looking forward to your feedback.
Regards
Shweta Agrawal
B.Tech IV YR CSE
IIT Roorkee
Hi,
He is a first draft of the investigation for "page load time" with a
proposed action plan:
http://dev.xwiki.org/xwiki/bin/view/Design/PageLoadTime
My next step will be to run a "manual" test and take some measures and
propose "obvious" improvements we could make if there are any.
Comments welcome. Questions are:
- are the goals ok
- are the measures the right ones
- can we run automated measures
- what is missing in this document
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost