JForm for inserting images

[elin]

Hi,

In Jform we currently have: imagelist (makes a drop down of images in
a given folder which must be selected in the xml ), media (makes a
modal that 404s) and media manager (which has a fatal error). Various
ones are used in various places. I think we need to decide which is
the right one and then use it consistently to create a consistent UI.

I favor having a modal if it will let you access folders (unlike
imagelist). But no matter what, I think a decision needs to be made.

Elin

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Andrew Eddie]

The decision is easy. Yes, there should be a modal version to select
an image much like the "Image" button at the bottom of an editor.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Artyom Bisyarin]

On Sat, 17 Apr 2010 00:30:15 +0300, elin <elin....@gmail.com> wrote:

> Hi,
>
> In Jform we currently have: imagelist (makes a drop down of images in
> a given folder which must be selected in the xml ), media (makes a
> modal that 404s) and media manager (which has a fatal error). Various
> ones are used in various places. I think we need to decide which is
> the right one and then use it consistently to create a consistent UI.
>
> I favor having a modal if it will let you access folders (unlike
> imagelist). But no matter what, I think a decision needs to be made.

I think so too.

Buy the way, I've fixed image field as an example of usage of the new
JFormFieldModalExternal class.

If you want, take a look at this thread (there is a link to new classes in
the last message):
http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/9a60013d76fd3569/c2559556f897934e

--
Artyom

[elin]

So media or mediamanager?

@Artyom I think it would be great if you would put your work into the
tracker. That's the way to get it into the work flow.

I'm happy to do my usual going through the xml and making things
consistent as long as I know what it is I'm supposed to do.

Also, speaking of having a button like in the editor, using a editarea
doesn't give you the image button ... is that something someone feels
like working on? And example is in the single contact edit layout.

Elin

On Apr 16, 5:54 pm, "Artyom Bisyarin" <arts...@ukr.net> wrote:

> On Sat, 17 Apr 2010 00:30:15 +0300, elin <elin.war...@gmail.com> wrote:
> > Hi,
>
> > In Jform we currently have: imagelist (makes a drop down of images in
> > a given folder which must be selected in the xml ), media (makes a
> > modal that 404s) and  media manager (which has a fatal error). Various
> > ones are used in various places. I think we need to decide which is
> > the right one and then use it consistently to create a consistent UI.
>
> > I favor having a modal if it will let you access folders (unlike
> > imagelist). But no matter what, I think  a decision needs to be made.
>
> I think so too.
>
> Buy the way, I've fixed image field as an example of usage of the new  
> JFormFieldModalExternal class.
>
> If you want, take a look at this thread (there is a link to new classes in  

> the last message):http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/9a...

[Artyom Bisyarin]

On Sat, 17 Apr 2010 01:26:30 +0300, elin <elin....@gmail.com> wrote:

> @Artyom I think it would be great if you would put your work into the
> tracker. That's the way to get it into the work flow.

Thanks in advice. I'll add it into the tracker soon.

> I'm happy to do my usual going through the xml and making things
> consistent as long as I know what it is I'm supposed to do.
>
> Also, speaking of having a button like in the editor, using a editarea
> doesn't give you the image button ... is that something someone feels
> like working on? And example is in the single contact edit layout.

Simply, if someone wants buttons in his editor, he should use
"buttons=true" in a {YOUR_FORM}.xml file:

<field readonly="false" name="ed" type="editor" id="ed1" required="false"
buttons="true" label="Ed Test" description="Test">
</field>

Do you need this? I correctly understand you?

[infograf768]

We badly need the modal.
Look at banners and selecting an image to see what I mean.
Any code proposal welcome.

On 17 avr, 01:31, "Artyom Bisyarin" <arts...@ukr.net> wrote:

[elin]

Artyom,

What I need is for the editor-xtd plugin button-image and ideally
button-article to run (and render) whenever the editor is used.
Pagebreak and readmore shouldn't because they don't mean anything
outside the context of com_content, at least for core components.

Andrew told me he'll look at media and mediamanager and tell me which
one should be used. So at that point I'm happy to go though all the
xml and make it consistent unless someone else wants to take that on.

Elin

[Artyom Bisyarin]

On Sat, 17 Apr 2010 07:47:33 +0300, infograf768 <infog...@gmail.com>
wrote:

> We badly need the modal.
> Look at banners and selecting an image to see what I mean.
> Any code proposal welcome.

I have tested my "modalExternalImage" field (we can rename it to "image |
modal | modalmanager") in this layout and it fixes image insertion issue.
But now I see another issue in com_banners -- it does not saves an image
URL (moreover, I don't see a field in the jos_banners DB table to store
this value). I will look at all issues with modal windows (or on those
which became visible after fixing a modal issue) and re-write existing
fields which use modal windows to match the new style. But I want to do
this when the basic modal code will be committed to the trunk.

And Elin asks:
>> So media or mediamanager?
Technically, now com_media shows only images in the popup-mode. That's why
I call my new form field "modalExternalImage".
But if someone works on com_media's refactoring in order to allow to
choose any media file in the popup-mode (or maybe this refactoring is
planned), then let's decide how we want to name the generic field which
uses com_media. Then I will rename my "modalExternalImage" field to
"media" or "mediamanager" and will put the new classes into the bug
tracker.

[elin]

I'm not sure what you mean, but we certainly don't want users to be
able to insert things from off site using the media manager. It's for
accessing and managing images that you have on your server in your
images folder. You should use html or the editor's image button to
insert other images.

Elin

On Apr 17, 9:12 am, "Artyom Bisyarin" <arts...@ukr.net> wrote:
> On Sat, 17 Apr 2010 07:47:33 +0300, infograf768 <infograf...@gmail.com>  

[Artyom Bisyarin]

Elin, I don't mean that com_media should allow users to insert things from
off site.
I just want to point out that at the moment com_media in the popup-mode
allows to choose images only.
That's why we can't honestly name a field that uses com_media "media",
because com_media shows only images and not all media files.

[Artyom Bisyarin]

On Sat, 17 Apr 2010 15:57:32 +0300, elin <elin....@gmail.com> wrote:

> Artyom,
>
> What I need is for the editor-xtd plugin button-image and ideally
> button-article to run (and render) whenever the editor is used.

There is a bug in "libraries/joomla/form/fields/editor.php"

I have prepare a patch to fix it:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=20173

After applying the patch you will be able to put this into your
"{FORM_NAME}.xml":

= = =

<field readonly="false" name="ed" type="editor" id="ed1" required="false"

label="Ed Test" description="Test" buttons="pagebreak,readmore">
</field>
= = =

In "buttons='pagebreak,readmore'" you should list button names which you
don't want to show.

Or it's would be better when "pagebreak" and "readmore" buttons are
removed by default?

[elin]

Great thanks.I'll test the patch tonight.

As far as I know you can specify most extensions using insert in the
media manager but it will always use the img tag. The extensions are
controlled in the input filters and the editors. settings. One
reason I've hesitant about the media field is I have wondered if the
intent is to use that for embed instead of img. I think I asked a
while ago what it was for but it was never answered. . I know you've
been working at this for months but for others here are a couple of
older discussions.


http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/8efaf4269d9dd89c/2b5af2a5fa8be18c

http://groups.google.com/group/joomla-dev-cms/browse_thread/thread/8cd3021ec7caf09/866a2fdcc3f3776b

Maybe we should think about what the media and medialist views and or
images and imagelist are supposed to be used for? The admin seems to
be using media. Is images legacy code that can get cut or is there
intent to use both?


Elin

On Apr 17, 11:14 am, "Artyom Bisyarin" <arts...@ukr.net> wrote:

> On Sat, 17 Apr 2010 15:57:32 +0300, elin <elin.war...@gmail.com> wrote:
> > Artyom,
>
> > What I need is for the editor-xtd plugin button-image and ideally
> > button-article  to run (and render) whenever the editor is used.
>
> There is a bug in "libraries/joomla/form/fields/editor.php"
>

> I have prepare a patch to fix it:http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEd...

[Hannes Papenberg]

Hi Elin,
on my list, com_media is ready for a complete overhaul. It needs a
complete rewrite with support for files other than images and editors
for those files. This will however have to wait till 1.7

Hannes

[Artyom Bisyarin]

On Sat, 17 Apr 2010 20:47:49 +0300, Hannes Papenberg
<hack...@googlemail.com> wrote:

> on my list, com_media is ready for a complete overhaul. It needs a
> complete rewrite with support for files other than images and editors
> for those files. This will however have to wait till 1.7

OK. Thank for clarifying this, Hannes.

So how we should call the modal form field for image insertion with
com_media?
I have called it "modalExternalImage" when I was working on the "Fix up
Image Form field" patchwork. But this name is too technical and too long.
It is possible to name this form field as we wish.

Here is the possible candidates: image, media, mediamanager.

[elin]

Hi Hannes,

We're actually not talking about com_media so much as talking about
the form field and plugin that are supposed to access it.
however, can you please clarify whether there should be both media/
medialist and images/imagelist? it image/imagelist is not currently
being used.

Elin

On Apr 17, 3:31 pm, "Artyom Bisyarin" <arts...@ukr.net> wrote:
> On Sat, 17 Apr 2010 20:47:49 +0300, Hannes Papenberg  
>

[Hannes Papenberg]

Hi Elin,
hi Artyom,
I know that we are talking about the formfield, but since com_media
currently practically only supports images, the question is solved
easily for me. Create one named media, that we can extend in 1.7 with
options to show images, documents or similar stuff. This one for now
wont do more than the image field, that also uses com_media and shows
just the images to be selected in the modal.

A bigger issue is, that com_media currently always creates a complete
image tag and not just returns the imagepath. We will have to change it
to call a function that each button/formfield can define on its own
instead of hardcoding that into the media manager itself.

Hannes

[elin]

Actually the on called media gives a 404 error.

Elin

[Artyom Bisyarin]

On Sun, 18 Apr 2010 02:19:34 +0300, Hannes Papenberg
<hack...@googlemail.com> wrote:

> Hi Elin,
> hi Artyom,
> I know that we are talking about the formfield, but since com_media
> currently practically only supports images, the question is solved
> easily for me. Create one named media, that we can extend in 1.7 with
> options to show images, documents or similar stuff. This one for now
> wont do more than the image field, that also uses com_media and shows
> just the images to be selected in the modal.

Ok, Hannes, I will rename my "modalExternalImage" field to "media" and put
the classes to the bugtracker.

> A bigger issue is, that com_media currently always creates a complete
> image tag and not just returns the imagepath.

To solve such problems each JFormFieldModal's subclass has a partner
javascript class. End a js-class has preInsType and postInsType methods.
This methods executed on each value insertion. When we define a
PHP-subclass of JFormFieldModal we can easily extend or add new js-methods
just using getJsMethodXXX() php-methods:

= = =
class JFormFieldMedia extends JFormFieldModalExternal
{
protected $link =
'index.php?option=com_media&amp;view=images&amp;tmpl=component&amp;e_name={FIELD_ID}';

static protected function getJsMethodPreInsType()
{
$script = <<<EOF

imgTag = this.value;
re = /src=['"]([^'"]+)['"]/;
re.test(imgTag);
this.value = RegExp.$1;

EOF;
return $script;
}
= = =

Above definition will lead to creation of this js-class:

= = =
var mediaField = new Class({
Extends: modalExternalField,
preInsType: function() {
imgTag = this.value;
re = /src=['"]([^'"]+)['"]/;
re.test(imgTag);
this.value = RegExp.$1;
}
});

// And then a js-object will be created for each form field on the client
side.
...
= = =

Here imageField::preInsType() javascript method makes image paths from
image tags.

One problem is solved. But com_media knows nothing about our javascript
field objects.
Don't worry, solution exists.

> We will have to change it
> to call a function that each button/formfield can define on its own
> instead of hardcoding that into the media manager itself.

When we will rewrite com_media then it simply can use a reference for the
active field object which JFormFieldModal creates for us.
Also we can make a new parameter for com_media, say, "function" and pass
to it a string with js-object name and js-method name. With this approach
we also can pass ordinary function names to com_media.

Now I resolved this problem with javascript proxy functions:

We should define a PHP-class with "getJsProxyFunc()" method:

= = =
class JFormFieldMedia extends JFormFieldModalExternal
{
protected $link =
'index.php?option=com_media&amp;view=images&amp;tmpl=component&amp;e_name={FIELD_ID}';

static protected function getJsProxyFunc()
{
$name = 'jInsertEditorText';
$args = array('value', 'id');

$fields = self::$jsFieldStorage;
$insert = self::$jsInsMethod;
$body = <<<EOF

// Proxy function for the image field objects.
// In the feature, com_media should be rewriten to support field
objects.
{$fields}[id].$insert(value);
EOF;
return array($name, $body, $args);
}
}
= = =

Above definition will lead to creation of this js-code:
= = =

var mediaField = new Class({
Extends: modalExternalField
});

function jInsertEditorText(value, id) {
// Proxy function for the image field objects.
// In the feature, com_media should be rewriten to support field objects.
formFields[id].insert(value);
}
= = =

The proxy function should find needed javascript field object and execute
it's "insert" method with needed arguments.

[JM Simonet]

FYI, Ian is working on com_media in a branch.
JM

--
>Please keep the Subject wording in your answers
This e-mail and any attachments may be confidential. You must not
disclose or use the information contained in this e-mail if you are
not the
intended recipient. If you have received this e-mail in error, please
notify us immediately and delete the e-mail and all copies.
-----------------------------------------------------------
Jean-Marie Simonet / infograf768
Joomla! Translation Coordination Team