Issue 404 in simal: HTML in project description not parsed
si...@googlecode.com
Owner: ----
Labels: Type-Defect
New issue 404 by Stev...@gmail.com: HTML in project description not parsed
http://code.google.com/p/simal/issues/detail?id=404
It would be useful to have HTML in project descriptions (<description>) At
the moment, on the project detail page, this is displayed in a <textarea>
component, so the HTML code is shown, instead of being rendered.
(I could have sworn I saw references to HTML in some JUnit tests...)
si...@googlecode.com
Status: Accepted
Labels: -Type-Defect Type-Enhancement Priority-High Milestone-0.3
Component-Webapp
Comment #1 on issue 404 by ross.gardler: HTML in project description not
parsed
http://code.google.com/p/simal/issues/detail?id=404
(No comment was entered for this change.)
Ross Gardler
On 07/03/2011 05:53, si...@googlecode.com wrote:
> Status: New
> Owner: ----
> Labels: Type-Defect
>
> New issue 404 by Stev...@gmail.com: HTML in project description not parsed
> http://code.google.com/p/simal/issues/detail?id=404
>
> It would be useful to have HTML in project descriptions (<description>)
> At the moment, on the project detail page, this is displayed in a
> <textarea> component, so the HTML code is shown, instead of being rendered.
I agree with this, I'm pretty sure that my original UI code did support
HTML but the move to the edit form has broken it.
I'm pretty happy with the way my widget experiments is panning out
(although IE doesn't work well with them right now).
It would be good if people could review the experiment with the
projectList and featuredProject widget and let me know what they think.
I'm starting to think that we could use widgets for user interface (read
only) and wicket for editor interfaces.
Comments welcome.
Ross
Sander W G van der Waal
> contri...@googlegroups.com] On Behalf Of Ross Gardler
> Sent: 07 March 2011 16:30
> To: simal-con...@googlegroups.com
> Subject: Widgets for users, Wicket for admin (was Re: [Simal] Issue 404
> in simal: HTML in project description not parsed)
>
> From the issue tracker:
>
> On 07/03/2011 05:53, si...@googlecode.com wrote:
> > Status: New
> > Owner: ----
> > Labels: Type-Defect
> >
> > New issue 404 by Stev...@gmail.com: HTML in project description not
> parsed
> > http://code.google.com/p/simal/issues/detail?id=404
> >
> > It would be useful to have HTML in project descriptions
> (<description>)
> > At the moment, on the project detail page, this is displayed in a
> > <textarea> component, so the HTML code is shown, instead of being
> rendered.
>
> I agree with this, I'm pretty sure that my original UI code did support
> HTML but the move to the edit form has broken it.
That's correct. The move to a textarea component broke this. My approach
to the whole editing issue was to do it using css based on the wicket docs [1].
I chose this
because I wanted to prevent creating a whole new set of classes just for
the editing, which would potentially lead to a lot of duplication code.
> I'm pretty happy with the way my widget experiments is panning out
> (although IE doesn't work well with them right now).
>
> It would be good if people could review the experiment with the
> projectList and featuredProject widget and let me know what they think.
> I'm starting to think that we could use widgets for user interface
> (read
> only) and wicket for editor interfaces.
I've reviewed the widgets and think it's a good start. The setup is still
very cumbersome though, once there's a Wookie release we should really
embed it into Simal.
I'm not really sure about taking the widgets out as a separate project and
using Ant for that. If we're looking to integrate the widgets in the regular
webapp I'd rather keep it in the web project. Was the problem with the
Maven setup I created for the doapcreator widget?
Sander
[1] https://cwiki.apache.org/WICKET/how-to-use-the-same-form-for-editing-and-new.html
> Comments welcome.
>
> Ross
>
> --
> You received this message because you are subscribed to the Google
> Groups "Simal contributors" group.
> To post to this group, send an email to simal-
> contri...@googlegroups.com.
> To unsubscribe from this group, send email to simal-
> contributors...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/simal-contributors?hl=en-GB.
Steve Bennett
<sander.v...@oucs.ox.ac.uk> wrote:
> That's correct. The move to a textarea component broke this. My approach
> to the whole editing issue was to do it using css based on the wicket docs [1].
> I chose this
> because I wanted to prevent creating a whole new set of classes just for
> the editing, which would potentially lead to a lot of duplication code.
The downside of this from my point of view is that the static
presentation (what most people will see) is downgraded, in order to
provide the editing feature (which few people will see). It's a pity
that Wicket doesn't have a way to show say, div or p tags in readonly
mode, and textareas in editing mode.
Steve
Ross Gardler
I agree with Steve here, but we only find this out by trying it.
I think my proposal to use widgets for user interface and Wicket for
admin means we won't need to worry about presentation limitations of
wicket (it's a great framework, but I don't thin it's ideal for what we
are doing).
Ross
Ross Gardler
>> From: simal-con...@googlegroups.com [mailto:simal-
>> contri...@googlegroups.com] On Behalf Of Ross Gardler
>> Sent: 07 March 2011 16:30
>> To: simal-con...@googlegroups.com
...
>> I'm pretty happy with the way my widget experiments is panning out
>> (although IE doesn't work well with them right now).
>>
>> It would be good if people could review the experiment with the
>> projectList and featuredProject widget and let me know what they think.
>> I'm starting to think that we could use widgets for user interface
>> (read
>> only) and wicket for editor interfaces.
>
> I've reviewed the widgets and think it's a good start. The setup is still
> very cumbersome though, once there's a Wookie release we should really
> embed it into Simal.
A Wookie release is very near, so that's really not a problem.
> I'm not really sure about taking the widgets out as a separate project and
> using Ant for that. If we're looking to integrate the widgets in the regular
> webapp I'd rather keep it in the web project. Was the problem with the
> Maven setup I created for the doapcreator widget?
My motivations were:
- the widgets are useful without the rest of the web interface code so
why hide them in that module?
- using the ANT scripts means the documentation provided by Wookie for
developing, testing and building widgets applies here - less for us to
document and less for us to implement in the Simal connector
- I don't see any drawback with having the code in a separate module
I'll expand on this last point since you ask specifically about that.
Your Maven script only allowed for deployment, as part of Simal. It did
not support the full development cycle of a widget.
I'll admit that it didn't occur to me that it might make it more
difficult for you to manage the deployed instance of Simal. I don't know
your processes there, and I may have temporarily made things a littlre
more difficult. But there is no reason why this should be the case once
we've either made the widgets module a submodule of the web module
(maven solution) or make the web modules maven build call the
appropriate Ant tasks in the widget module.
Note, we already have an issue for making the modules relate to one
another correctly using maven. See
http://code.google.com/p/simal/issues/detail?id=202
Ross
Sander W G van der Waal
> contri...@googlegroups.com] On Behalf Of Ross Gardler
> To: simal-con...@googlegroups.com
> Subject: Re: Widgets for users, Wicket for admin (was Re: [Simal] Issue
> 404 in simal: HTML in project description not parsed)
>
> > On 18 March 2011 04:20, Sander W G van der Waal
> > <sander.v...@oucs.ox.ac.uk> wrote:
> >
> >> That's correct. The move to a textarea component broke this. My
> approach
> >> to the whole editing issue was to do it using css based on the
> wicket docs [1].
> >> I chose this
> >> because I wanted to prevent creating a whole new set of classes just
> for
> >> the editing, which would potentially lead to a lot of duplication
> code.
> >
> > The downside of this from my point of view is that the static
> > presentation (what most people will see) is downgraded, in order to
> > provide the editing feature (which few people will see). It's a pity
> > that Wicket doesn't have a way to show say, div or p tags in readonly
> > mode, and textareas in editing mode.
>
> I agree with Steve here, but we only find this out by trying it.
Yes, you're both right and I just hadn't realised it downgraded the presentation
when committing this code.
> I think my proposal to use widgets for user interface and Wicket for
> admin means we won't need to worry about presentation limitations of
> wicket (it's a great framework, but I don't thin it's ideal for what we
> are doing).
My main problem with Wicket is the static markup of the HTML which makes it
hard to do multiple things conditionally on a page without overriding some
core Wicket methods leading to highly unreadable code. But whenever I check
the Wicket docs that is how they do it so I'm not sure there's a better way..
In short I agree the split in use of widgets/Wicket would be a good thing. :)
Sander
Steve Bennett
> and featuredProject widget and let me know what they think. I'm starting to
> think that we could use widgets for user interface (read only) and wicket
> for editor interfaces.
Would it be possible to do it the other way around? I'm not really
thrilled by the idea of having scrolling IFRAME elements to display
static content. It seems really quite complicated for something
simple, will probably be slower (judging from the time it takes
doapcreator to load), less accessible/usable...
I guess I'm wondering at this point: if it's so hard to cleanly write
something which pulls data out of a database and displays a static web
page with it using Wicket, then what exactly is Wicket's core use
case?
I think I understand what Sander means about not being able to do
things conditionally (and I find it a very frustrating limitation that
it is considered an error if there is not an HTML element
corresponding to every Java Wicket element *and vice versa*), but it
seemed bearable.
Sorry for the negativity...but we're getting quite close to deploying
Simal live in read-only mode, so I'm a bit concerned about what these
changes are likely to mean for us.
Steve
Ross Gardler
On 18 Mar 2011, at 09:36, Steve Bennett <ste...@gmail.com> wrote:
> On 8 March 2011 03:30, Ross Gardler <rgar...@apache.org> wrote:
>> and featuredProject widget and let me know what they think. I'm starting to
>> think that we could use widgets for user interface (read only) and wicket
>> for editor interfaces.
>
> Would it be possible to do it the other way around?
Probably not, at least not in terms of our resources here. Of course you can continue to enhance the wicket UI fir end users. All we need do is separate out the admin and user UI pages. They can still share components.
> I'm not really
> thrilled by the idea of having scrolling IFRAME elements to display
> static content. It seems really quite complicated for something
> simple, will probably be slower (judging from the time it takes
> doapcreator to load), less accessible/usable...
Actually, the long term plan (in my head until now) would be to drop wicket entirely from the user UI. the alternative would be Apache Rave (incubating) which is a portal engine for widgets and gadgets.
That wil considerably enhance our ability to use widgets effectively.
As for scrolling iframes - that need not be the case. It's just that the UI in the test widgets have not been optimised yet. Have you looked at the projectList widget yet? It's closer to what we want (but only in Chrome and FF right now).
From a user perspective it should look the same, or similar.
From a loading perspective it should, in fact be faster in the long run as we can implement client side caches.
> I guess I'm wondering at this point: if it's so hard to cleanly write
> something which pulls data out of a database and displays a static web
> page with it using Wicket, then what exactly is Wicket's core use
> case?
It's nit that it's hard. It's that it dies not suit our use case here, we want to embed information frim Simal in other webapps without having to rebuild the UI for each application. So our efforts will go into that. If your use case is different then we welcome a more simple, static approach.
>
>
> Sorry for the negativity...but we're getting quite close to deploying
> Simal live in read-only mode, so I'm a bit concerned about what these
> changes are likely to mean for us.
Fair enough. Thanks for letting us know.
I suggest the best way forward is for us to no change the way the current UI works and to build a separate widget based interface. We currently use the wicket UI and need to continue to do so while we develop the widget based one. This means we will maintain the current UI and enhance admin features. Naturally we will support your work on the existing UI as that will benefit us in the short term.
Will that help you sleep at night?
Ross
>