[ http://issues.apache.org/jira/browse/GRFT-102?page=all ]
Evangelos Vlachogiannis updated GRFT-102:
-----------------------------------------
Attachment: patch.txt
I have replaced graffito kupu folder with kupu 1.3.5 "common" folder
contents and created the attached kupu.vm (I have only worked on the vm rest
are just extracted from puku dist. ). The editor looks fine but
when I post even if it seems to work (no error and redirect to folder
view on insert) I realized that it saves null content in db (meta looks
ok in db), so when i try to edit in iframe i get :
-----
The server encountered an internal error () that prevented it from
fulfilling this request.
exception
org.apache.ojb.broker.PersistenceBrokerException: Error invoking method
getContentStream
org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl.invoke(IndirectionHandlerDefaultImpl.java:334)
$Proxy30.getContentStream(Unknown Source)
org.apache.portals.graffito.servlets.GraffitoViewerServlet.doGet(GraffitoViewerServlet.java:67)
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
----
> Accessibility of portal content produced by authoring tool (kupu)
> -----------------------------------------------------------------
>
> Key: GRFT-102
> URL: http://issues.apache.org/jira/browse/GRFT-102
> Project: Graffito
> Issue Type: Improvement
> Components: Portlets
> Environment: Now running on ie and mozilla but for accessibility
> should support all browsers (maybe consider an applet editor ??)
> Reporter: Evangelos Vlachogiannis
> Priority: Minor
> Attachments: patch.txt
>
>
> Current version of kupu html editor produces really very bad markup in terms
> of accessibility but even for validity. For instance the font tag must really
> be avoided - use css style instead (like new 1.3.5 ver does). So a shift to
> the new version is a step towards better accessibility.
> Further, these are other relating problems that should be solved:
> 1. currently the editor portlet page in jetspeed contains 2 <html> tags which
> is really unacceptable!!.
> 2. Seeking for real xhtml (a base for accessibility) the editor should
> provide only semantic markup. For example could provide strong instead of
> bold and emphasis instead of underline or/and provide bold bolder etc using
> css.
> 3. For a portal creating content it actually means creating a page fragment.
> This means that the editor should allow for global markup and also provide
> apropriate css classes for styling according to JSR-168.
> Well, most of the issues are actually concern the editor and I might submit
> also to kupu but I find important to sync such work. This subject is actually
> one of my research interests and could find more information of this work
> (Portal Accessibility Guidelines Extensions) at
> http://www.syros.aegean.gr/users/evlach/page/
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
