List of available images in inputHTML component

[Alberto Molpeceres <al...@gmail.com>]

Hi,

I would like to change the inputHTML component so I can have a list of
available images instead of a inputText field. Of course this should
be optional.

Do you think it could be useful?.

   al.

Re: List of available images in inputHTML component

[Alberto Molpeceres <al...@gmail.com>]

On 11/14/05, Sylvain Vieujot <sv...@apache.org> wrote:
>  I don't like this external config file.
>  I think the proper way of doing this is to overload the Kupu method that
> configures the images library box.
>
>  So, we could pass to the inputHtml tag a Map containing images URLs as Key,
> and Images descriptions as held Objects.
>
>  What do you think ?

Yes, we could. Sure.

I had thought before looking how Kupu works, that I could pass a list
of ItemSelect to this component, and fill the combo list of the image
toolbox with it. Or give it the name of a directory and fill it with
everything it contains.

But this will not show the "beutiful" dialog box with images,
previews, and so on.

Propably I can generate kupu's imagelibrary configuration file
automatically  from both sources (list of something and directory
name), so we can use kupu's dialog box, which could be more pleasant,
but probably without image preview (or preview it the same size, I'll
take a look).

Anyway, I will try to remove this config file, neither do I like it.

   al.

Re: List of available images in inputHTML component

[Sylvain Vieujot <sv...@apache.org>]

Hello Alberto,

I really think we should configure the renderer by using a map with
URL/Name elements, as usually on a J2EE server, you can't access the
file system.
I see the "reading a folder" only as an optional nice to have feature.

About generating the XML Config file, I see 2 ways to do it :

1) Hack the Kupu javascript to put the configuration as javascript in
the page. I didn't look at this, but it shouldn't be too hard.

2) Use the new ResourceLoader to generate the config file as a response.
This might be a little harder to do, but it offers the advantage to be
running better with ajax. Indeed, with this, you could have an ajax'ed
fileupload component on the page, and Kupu would pickup those files
without any need to reload the page.
To see how this work, you might look in the sandbox, and I think there
is an example in the examples webapp too.

If you choose option 1, beware to implement the javascript in a separate
file by overloading the default code, as Kupu code is moving a lot, and
this ensures the smoothest transition while upgrading Kupu. BTW, Kupu is
at version 1.3.3 now, while MyFaces' Kupu is only at 1.3.

Sylvain.

On Wed, 2006-01-04 at 18:41 +0100, Alberto Molpeceres wrote:

> Hi Sylvain and everyone,
> 
> I'm again the guy who wanted to develop some image gallery
> functionality on inputHTML editor. I've been working offsite for a few
> weeks, but now I want to finish it. Today I've been updating my copy
> of MyFaces.
> 
> Well, if we want to use Kupu's image library (and I wnat to), I have
> to create an XML file with the content of the gallery. Here there are
> to posibilities: a map with image content, or simply read the content
> of a folder given as attribute to inputHTML tag. I like this second
> option, altough the first one is appealing too.
> 
> Well, the I need to write this file to a temp file or to generate it
> on the fly upon request using the resource extension filter. Could you
> help me with this?. I mean, could you say me which options makes more
> sense to you?. And if using a the extension filter, could you explain
> me how it works or how it should work?.
> 
> Any Idea or tip?.
> 
>   al.
> 
> On 11/14/05, Sylvain Vieujot <sv...@apache.org> wrote:
> >  I don't like this external config file.
> >  I think the proper way of doing this is to overload the Kupu method that
> > configures the images library box.
> >
> >  So, we could pass to the inputHtml tag a Map containing images URLs as Key,
> > and Images descriptions as held Objects.
> >
> >  What do you think ?
> >
> >  Sylvain.
> >

List of available images in inputHTML component

[Alberto Molpeceres <al...@gmail.com>]

Hi Sylvain and everyone,

I'm again the guy who wanted to develop some image gallery
functionality on inputHTML editor. I've been working offsite for a few
weeks, but now I want to finish it. Today I've been updating my copy
of MyFaces.

Well, if we want to use Kupu's image library (and I wnat to), I have
to create an XML file with the content of the gallery. Here there are
to posibilities: a map with image content, or simply read the content
of a folder given as attribute to inputHTML tag. I like this second
option, altough the first one is appealing too.

Well, the I need to write this file to a temp file or to generate it
on the fly upon request using the resource extension filter. Could you
help me with this?. I mean, could you say me which options makes more
sense to you?. And if using a the extension filter, could you explain
me how it works or how it should work?.

Any Idea or tip?.

  al.

On 11/14/05, Sylvain Vieujot <sv...@apache.org> wrote:
>  I don't like this external config file.
>  I think the proper way of doing this is to overload the Kupu method that
> configures the images library box.
>
>  So, we could pass to the inputHtml tag a Map containing images URLs as Key,
> and Images descriptions as held Objects.
>
>  What do you think ?
>
>  Sylvain.
>

Re: List of available images in inputHTML component

[Sylvain Vieujot <sv...@apache.org>]

I don't like this external config file.
I think the proper way of doing this is to overload the Kupu method that
configures the images library box.

So, we could pass to the inputHtml tag a Map containing images URLs as
Key, and Images descriptions as held Objects.

What do you think ?

Sylvain.

On Fri, 2005-11-11 at 10:36 +0100, Alberto Molpeceres wrote:

> Hi Sylvain,
> 
> I have already changed inputHTML component (diffs attached). Pretty
> simple, if you set in inputHTML's tag a property "imageLibrary" then
> library's icon appears in your page, and tries to use the given file
> to configure Kupu.
> 
> The main subject is this config file. It's an XML describing available
> images, and thus it's some kind of application specific. I suppose a
> new tag could be implemented, a tag that could build this description
> file from a folder's content, but then we would have to decide which
> refresh mechanism to use (per request, periodically, never).
> 
> I don't know what to do. To develop this tags... to let this XML
> generation up to each application developer... .
> 
> What do you think?. I have to do it for my proyect, so I'm going to do
> one of them anyway.
> 
>      al.

Re: List of available images in inputHTML component

[Alberto Molpeceres <al...@gmail.com>]

Hi Sylvain,

I have already changed inputHTML component (diffs attached). Pretty
simple, if you set in inputHTML's tag a property "imageLibrary" then
library's icon appears in your page, and tries to use the given file
to configure Kupu.

The main subject is this config file. It's an XML describing available
images, and thus it's some kind of application specific. I suppose a
new tag could be implemented, a tag that could build this description
file from a folder's content, but then we would have to decide which
refresh mechanism to use (per request, periodically, never).

I don't know what to do. To develop this tags... to let this XML
generation up to each application developer... .

What do you think?. I have to do it for my proyect, so I'm going to do
one of them anyway.

     al.

Re: List of available images in inputHTML component

[Sylvain Vieujot <sv...@apache.org>]

Yes, it would be very nice.
It's on my todo list since quite some times now.
Kupu already has some provision to do this.
It needs to be enabled and made compatible with JSF.

I would be happy to review and commit your patch on this.

Thanks,

Sylvain.

On Wed, 2005-11-09 at 19:41 +0100, Alberto Molpeceres wrote:

> Hi,
> 
> I would like to change the inputHTML component so I can have a list of
> available images instead of a inputText field. Of course this should
> be optional.
> 
> Do you think it could be useful?.
> 
>    al.