JGrid

439 views
Skip to first unread message

Hannes Papenberg

unread,
Sep 21, 2011, 12:36:33 PM9/21/11
to Joomla! CMS Development
Hi folks,
after a year, a new message from me...

I've recently made a pull request against the platform project and
introduced the class JGrid. This class is used to create HTML tables and
actually only delays the rendering of the table a little bit. The idea
is, that you push all your data that you want to have in the table into
the JGrid object and then send it to the layout. In the layout you
simply call the rendering function and the table is created.

There are a few benefits resulting from using this class:
1. When pushing in the data in the view, but rendering it in the layout,
you could modify the content of the table with a plugin between those
two steps. You can remove rows, add classes to certain columns or
add/remove/reorder columns.
2. You don't have to pay attention to table mark-up, its done
automatically correct for you.
3. Having all the standard work done in the class, we are simplifying
the layouts, resulting in the end in a common layout for all list views
that looks kinda like echo $filters; echo $table Changes to the layouts
would only have to be done once and would all work directly in all
components.

In a future version, we might add other classes that extend from JGrid
and automatically generate rows/columns from data that is being handed
over. Regarding #1 and #3, I'm already working on a proposal for this.

The question now is, if I should start converting the list views in
Joomla to using JGrid and if that all can be part of 2.5 already. Please
advice.

Hannes

Rouven Weßling

unread,
Sep 21, 2011, 2:58:50 PM9/21/11
to joomla-...@googlegroups.com
Hi Hannes.

On 21.09.2011, at 18:36, Hannes Papenberg wrote:

> 3. Having all the standard work done in the class, we are simplifying
> the layouts, resulting in the end in a common layout for all list views
> that looks kinda like echo $filters; echo $table Changes to the layouts
> would only have to be done once and would all work directly in all
> components.

This sound very interesting and could help make things, especially in the backend, more consistent. Without looking at your code I have one question and that is if it's possible for templates to change the markup and if so how much flexibility they have.

> The question now is, if I should start converting the list views in
> Joomla to using JGrid and if that all can be part of 2.5 already. Please
> advice.

I have no strong opinion in either direction but I'd like to warn that this will most likely break 3rd party admin templates. IMO not a deal breaker but something to be aware of.

Best regards
Rouven

Mark Dexter

unread,
Sep 21, 2011, 3:11:49 PM9/21/11
to joomla-...@googlegroups.com
Again, I believe that we want to be conservative in making changes for version 2.5 that could have backward compatibility issues. Version 3.0 is where we can get a bit "wild and crazy" and make changes that might require extension devs to do some work. If an extension needs some work to convert it to Joomla version 3.0, that's not the end of the world. However, I don't think we want to require extension devs to make changes to existing 1.6/1.7 extensions to work with 2.5. At least that is my interpretation of the dev cycle and the role of LTS releases in the cycle.

Getting this functionality into the platform, on the other hand, is great. That gets it out there for people to use and work the kinks out.

Mark


--
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.


Hannes Papenberg

unread,
Sep 21, 2011, 3:20:50 PM9/21/11
to joomla-...@googlegroups.com
Hi Rouven,
the class only generates the table output that you specify and you can
change all the markup the way you want. The only thing that is cast in
stone is the markup that you use in a table as defined by HTML4. The
whole class was written with the possibility in mind to modify the
tables without having to copy the complete layout, for example adding
zebra-stripes or drag and drop sorting or adding classes.

Hannes

Hannes Papenberg

unread,
Sep 21, 2011, 3:26:48 PM9/21/11
to joomla-...@googlegroups.com
There would be no change for templates, components or whatever between
1.7 and 2.5. The data available in the layout would still be the same,
except that we would add the JGrid object to the environment, which
could be used to render the table instead of doing it manually in the
layout. Basically the views currently look like this:
View:
1. fetch data
2. modify data slightly (create URLs and such)
3. push data into the JView object

Layout:
1. Get data from the JView object and render it the way you like

With the change with JGrid, it would look something like this:
View:
1. fetch data
2. modify data slightly
3. push data into the JView object
4. Create a JGrid object and push it into the JView object
5. Fill the JGrid object with the rendered data for the different cells

Layout:
1. Get JGrid object and invoke toString()
- or -
1. Get data from the JView object and render it the way you like

There would be no backwards compatibility issues.

Hannes

Am 21.09.2011 21:11, schrieb Mark Dexter:
> Again, I believe that we want to be conservative in making changes for
> version 2.5 that could have backward compatibility issues. Version 3.0
> is where we can get a bit "wild and crazy" and make changes that might
> require extension devs to do some work. If an extension needs some
> work to convert it to Joomla version 3.0, that's not the end of the
> world. However, I don't think we want to require extension devs to
> make changes to existing 1.6/1.7 extensions to work with 2.5. At least
> that is my interpretation of the dev cycle and the role of LTS
> releases in the cycle.
>
> Getting this functionality into the platform, on the other hand, is
> great. That gets it out there for people to use and work the kinks out.
>
> Mark
>

> <mailto:joomla-...@googlegroups.com>.


> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

Mark Dexter

unread,
Sep 21, 2011, 3:41:53 PM9/21/11
to joomla-...@googlegroups.com
Sounds interesting. Sounds like the thing to do is to create a branch and an entry in the Feature Tracker and people can test and evaluate and see what they think. Mark

> On Wed, Sep 21, 2011 at 11:58 AM, Rouven Weßling <m...@rouvenwessling.de

Hannes Papenberg

unread,
Oct 2, 2011, 12:23:36 PM10/2/11
to joomla-...@googlegroups.com
Since there are some problems with my account on joomlacode.org, I
forked the repo on github with the CMS code and implemented the user
list view with JGrid. You can find the branch here:
https://github.com/Hackwar/joomla-cms/tree/jgrid

The content of the table is now generated in the view.html.php file, as
you can see in
/administrator/components/com_users/views/users/view.html.php and the
only thing in the layout that is really necessary (for the table) is the
echo $this->table; To show the potential of this solution, I also
changed JView (the change which I'm still proposing for the platform),
which now fires a plugin-event between display() and loading the layout,
which allows to modify that table further.

Now, at some point we could standardize so far, that most of the stuff
that happens in several rows in the code of the table generating, could
be abstracted out, so that JView can automatically generate these
tables. For designers, this object allows you to touch each row
seperately and even each cell, changing classes, adding attributes or
removing them. (Of course also replacing the content of a cell, too)
Last but not least, this code is quite a bit faster than the layout up
till now, since the switch between HTML- and PHP-mode (<?php ?>) seems
to require quite some processing-time.

Looking forward to your comments and your approval.

Hannes

> Am 21.09.2011 21 <tel:21.09.2011%2021>:11, schrieb Mark Dexter:
> > Again, I believe that we want to be conservative in making
> changes for
> > version 2.5 that could have backward compatibility issues.
> Version 3.0
> > is where we can get a bit "wild and crazy" and make changes that
> might
> > require extension devs to do some work. If an extension needs some
> > work to convert it to Joomla version 3.0, that's not the end of the
> > world. However, I don't think we want to require extension devs to
> > make changes to existing 1.6/1.7 extensions to work with 2.5. At
> least
> > that is my interpretation of the dev cycle and the role of LTS
> > releases in the cycle.
> >
> > Getting this functionality into the platform, on the other hand, is
> > great. That gets it out there for people to use and work the
> kinks out.
> >
> > Mark
> >

> > On Wed, Sep 21, 2011 at 11:58 AM, Rouven We�ling
> <m...@rouvenwessling.de <mailto:m...@rouvenwessling.de>

> > <mailto:joomla-...@googlegroups.com


> <mailto:joomla-...@googlegroups.com>>.
> > To unsubscribe from this group, send email to
> > joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>

> > <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com
> <mailto:joomla-dev-cms%252Buns...@googlegroups.com>>.

Mark Dexter

unread,
Oct 4, 2011, 12:31:50 AM10/4/11
to joomla-...@googlegroups.com
Hannes, please make sure to create an issue in the CMS Feature Tracker here: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8549

and set it to Pending. That way people will know to test it for possible inclusion into v 2.5. Also, is possible, please make sure the system tests pass with this feature patch.

Thanks. Mark

>     > On Wed, Sep 21, 2011 at 11:58 AM, Rouven Weßling
>     <m...@rouvenwessling.de <mailto:m...@rouvenwessling.de>

Hannes Papenberg

unread,
Oct 4, 2011, 2:41:17 AM10/4/11
to joomla-...@googlegroups.com
Hi Mark,
as I wrote, I have some problems with getting/reactivating my account on
joomlacode, which means that I currently don't have any means to login
to joomlacode and thus can't open a new ticket.

The system tests should pass, since nothing has really changed. The
output is exactly the same and the PHP environment has only added
variables and none of the existing ones were changed.

Hannes

Am 04.10.2011 06:31, schrieb Mark Dexter:
> Hannes, please make sure to create an issue in the CMS Feature Tracker
> here:
> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8549
> <http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8549>
>
> and set it to Pending. That way people will know to test it for
> possible inclusion into v 2.5. Also, is possible, please make sure the
> system tests pass with this feature patch.
>
> Thanks. Mark
>
> On Sun, Oct 2, 2011 at 9:23 AM, Hannes Papenberg
> <hack...@googlemail.com <mailto:hack...@googlemail.com>> wrote:
>
> Since there are some problems with my account on joomlacode.org

> <http://joomlacode.org>, I

> Am 21.09.2011 21 <tel:21.09.2011%2021>:41, schrieb Mark Dexter:
> > Sounds interesting. Sounds like the thing to do is to create a
> branch
> > and an entry in the Feature Tracker and people can test and evaluate
> > and see what they think. Mark
> >
> > On Wed, Sep 21, 2011 at 12:26 PM, Hannes Papenberg
> > <hack...@googlemail.com <mailto:hack...@googlemail.com>

> <mailto:hack...@googlemail.com

> > > On Wed, Sep 21, 2011 at 11:58 AM, Rouven We�ling

> > > <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com
> <mailto:joomla-dev-cms%252Buns...@googlegroups.com>
> > <mailto:joomla-dev-cms%252Buns...@googlegroups.com
> <mailto:joomla-dev-cms%25252Bun...@googlegroups.com>>>.

Christophe Demko

unread,
Oct 4, 2011, 4:58:37 AM10/4/11
to Joomla! CMS Development
How is it possible to adapt the code for the hathor template (which
uses different markup in the table header for instance)?

On 4 Oct, 08:41, Hannes Papenberg <hackwa...@googlemail.com> wrote:
> Hi Mark,
> as I wrote, I have some problems with getting/reactivating my account on
> joomlacode, which means that I currently don't have any means to login
> to joomlacode and thus can't open a new ticket.
>
> The system tests should pass, since nothing has really changed. The
> output is exactly the same and the PHP environment has only added
> variables and none of the existing ones were changed.
>
> Hannes
>
> Am 04.10.2011 06:31, schrieb Mark Dexter:
>
>
>
>
>
>
>
> > Hannes, please make sure to create an issue in the CMS Feature Tracker
> > here:
> >http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBr...
> > <http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBr...>
> >     > <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>
> >     <mailto:hackwa...@googlemail.com
> ...
>
> read more »

Hannes Papenberg

unread,
Oct 4, 2011, 5:19:38 AM10/4/11
to joomla-...@googlegroups.com
Hi Christophe,
hathor would either generate the table like it is doing now, or it would
change the generated code in the layout like this:
$table->setActiveRow(0);
$table->addRowCell('username', '', array('class' => 'nowrap width-10'),
false); //changes the attributes of the cell at column "username" in the
header row without replacing the cells content

Maybe hathor could even largely remove its layout overrides and realize
the necessary changes with a simple plugin for all views, even for
components that are not part of core Joomla.

Hannes

>> read more �

elin

unread,
Oct 4, 2011, 7:06:33 AM10/4/11
to joomla-...@googlegroups.com
So you would be providing the code for that  in your proposed feature patch, correct?

If it will break anyone's site on clicking the one click update I personally think it is a  non starter, so in your feature patch you would probably want to implement some kind of legacy layer that is on by default. 

Elin

Hannes Papenberg

unread,
Oct 4, 2011, 7:14:43 AM10/4/11
to joomla-...@googlegroups.com
The proposed code is 100% backwards compatible. There is no need for a
legacy layer. There is no change to the output of the components and
there is no change in the environment that a layout is loaded into.

We could implement the changes to the layout overrides of the hathor
template or we could simply leave them the way they are now. It doesn't
make a difference in terms of functionality. The only difference would
be, that hathor would not benefit from the advantages of this class. But
yes, I would add that code in my proposed patch, if it is required.

Hannes

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.

> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/aVuOiZe7jIEJ.
> 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.

Nick Savov

unread,
Oct 4, 2011, 9:20:24 AM10/4/11
to joomla-...@googlegroups.com
If Hannes' account is deactivated (for whatever reason) and it shouldn't
still be deactivated, could someone get that corrected for him or point
him in the right direction as to who to contact?

Kind regards,
Nick

Hannes Papenberg

unread,
Oct 4, 2011, 10:32:25 AM10/4/11
to joomla-...@googlegroups.com
Hi Nick,
I'm in contact with Mark and Sam about this. When I was banned, my
Joomlacode account was blocked, too, which resulted in me not being able
to edit my own data on Joomlacode. That is why I requested that account
to be deleted. Deleting it completely however is not possible and thus
there are currently issues reactivating it. I tried registering an
account with a different nickname and a different mailadress, but that
somehow didn't work either. Anyway, I'm in contact with them. ;-)

Hannes

Nick Savov

unread,
Oct 4, 2011, 10:36:26 AM10/4/11
to joomla-...@googlegroups.com
Awesome! :)

Andrea Tarr at Tarr Consulting

unread,
Oct 4, 2011, 10:41:28 AM10/4/11
to joomla-...@googlegroups.com
I plan on looking at this shortly, but it sounds like it adds functionality that could be used at will rather than requiring changes to what exists.

The concerns I have (which may be irrelevant once I look at the patch) is with a growing trend to move  html outside of the overrideable layouts and the concern that more php knowledge is being required to change layouts or to override that html. 

Hathor is overriding layouts when necessary for accessibility purposes. Some of that has functionality has made its way into the core layouts (thanks, Rouven!) and in those cases we have done away with the overrides. If JGrid is creating accessible html then there's no reason why we can't do the same thing. If it's not, then I'll supply some proposed changes :)

Andy

Andrea Tarr

Tarr Consulting




Christophe Demko

unread,
Oct 4, 2011, 11:17:50 AM10/4/11
to Joomla! CMS Development
Hi Hannes,
After looking at the code of JGrid,

-it seems that you forget to display the option for a row:
the test unit does not cover the real ouput:

/**
* Test for JGrid::__toString method.
*/
public function test__toString()
{
$table = new JGridInspector();
$table->addColumn('testCol1');
$table->addRow(array('class' => 'test1'));
$table->addRowCell('testCol1', 'testcontent1', array('class' =>
'1'));

$this->assertThat(
"<table><tbody>\n\t<tr class=\"test1\">\n\t\t<td class=
\"1\">testcontent1</td>\n\t</tr>\n</tbody></table>",
$this->equalTo((string)$table)
);
}

This test unit does not pass

-the code
$table->addRowCell('username', '', array('class' => 'nowrap
width-10'),
does not remove the "width" attribute
$table->addRowCell('username', '', array('class' => 'nowrap width-10',
'width'=>''),
writes an empty "width" attribute
maybe, we have to check the value of the attribute (!='') before
adding its output?

-the method function addRow($options = array(), $special = false)
could accept $special equal to 'footer' or 'header'
and there could be a addHeaderRow and addFooterRow method

-the same for getRows

On Oct 4, 3:20 pm, "Nick Savov" <n...@iowawebcompany.com> wrote:
> If Hannes' account is deactivated (for whatever reason) and it shouldn't
> still be deactivated, could someone get that corrected for him or point
> him in the right direction as to who to contact?
>
> Kind regards,
> Nick
>
>
>
>
>
>
>
> > Hi Mark,
> > as I wrote, I have some problems with getting/reactivating my account on
> > joomlacode, which means that I currently don't have any means to login
> > to joomlacode and thus can't open a new ticket.
>
> > The system tests should pass, since nothing has really changed. The
> > output is exactly the same and the PHP environment has only added
> > variables and none of the existing ones were changed.
>
> > Hannes
>
> > Am 04.10.2011 06:31, schrieb Mark Dexter:
> >> Hannes, please make sure to create an issue in the CMS Feature Tracker
> >> here:
> >>http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBr...
> >> <http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBr...>
> >>     >     > On Wed, Sep 21, 2011 at 11:58 AM, Rouven We�ling
> ...
>
> read more »

elin

unread,
Oct 4, 2011, 7:01:28 PM10/4/11
to joomla-...@googlegroups.com
No one gets guarantees on feature acceptance. Since the work is in the platform, you could perhaps work on one component at a time and submit it for people to start testing (like what we are doing with the JDatabasequery work). It does not have to be all or nothing, in other words, for example start with weblinks as the simplest example. That way extension developers can see how to use the API.   Personally, I would like to see us replace as many non accessible elements in the current core layouts and default templates as possible and in general move the Hathor work into the default. So another possibility is to  propose first a set of new overrides to replace the Hathor overrides, assuming that JGrid meets the accessibility standards and so on (I don't know enough about them to evaluate that).  




Elin

Andrea Tarr at Tarr Consulting

unread,
Oct 4, 2011, 8:43:26 PM10/4/11
to joomla-...@googlegroups.com
The biggest issue we have with removing Hathor overrides is with the jump menu used for the filters and the pagination display number. Those are inaccessible for keyboard use which is why in Hathor you have to use the Submit button for the filters. Until that is solved, we'll need to keep the overrides.

Andy
Andrea Tarr

Tarr Consulting






On Oct 4, 2011, at 7:01 PM, elin wrote:

No one gets guarantees on feature acceptance. Since the work is in the platform, you could perhaps work on one component at a time and submit it for people to start testing (like what we are doing with the JDatabasequery work). It does not have to be all or nothing, in other words, for example start with weblinks as the simplest example. That way extension developers can see how to use the API.   Personally, I would like to see us replace as many non accessible elements in the current core layouts and default templates as possible and in general move the Hathor work into the default. So another possibility is to  propose first a set of new overrides to replace the Hathor overrides, assuming that JGrid meets the accessibility standards and so on (I don't know enough about them to evaluate that).  




Elin

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/dBOHjL6R9rYJ.
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.

Sam Moffatt

unread,
Oct 5, 2011, 3:42:14 AM10/5/11
to joomla-...@googlegroups.com
Actually when you were banned you weren't blocked from JoomlaCode. In
fact your JoomlaCode account wasn't touched at all and you were free
to log into it. Your JoomlaCode account was modified when you didn't
abide by the terms of the ban and started posting on the Joomla! issue
tracker again. You could have quite freely worked on any other part of
JoomlaCode, most particularly your own projects, however you started
posting and commenting on issues in the bug tracker in violation of
the terms of your ban. At that point your JoomlaCode account was put
into a locked state but otherwise was untouched. Had you of not done
this then we wouldn't have been in this situation.

At some point after this you sent a legal threat to the Joomla!
project for your JoomlaCode account to be deleted and as per said
legal request modifications were made to your account. Unfortunately
due to relational integrity the system doesn't permit deletion of an
account (funny that) so I made modifications to the account to in my
opinion meet the regulatory requirements. These modifications were
done by me rather much under duress, as you can understand the threat
of the project being litigated against makes people want to resolve
things reasonably quickly which produces stress. I did something that
I believe was sufficient to meet your demands where technically
possible and complied with the relevant legislation you were
threatening to attempt to enforce against the project - all of which
consequently landing us in our present predicament. Again had you of
not request this or violated the terms of your ban we wouldn't be in
this situation.

However now we're at the situation where I have to revert all of what
I've done to restore access to your account. I've had my access to
JoomlaCode's servers reinstated last week so sometime this week I'll
try to find the time to dig back into JoomlaCode's database to work
out what I need to do again to restore your account.

Cheers,

Sam Moffatt
http://pasamio.id.au

>>>>     >     > On Wed, Sep 21, 2011 at 11:58 AM, Rouven Weßling

Hannes Papenberg

unread,
Oct 5, 2011, 4:14:30 AM10/5/11
to joomla-...@googlegroups.com
I don't want to argue about this. I have a different version of this
story, but maybe we could just stick to the story that I foolishly asked
the project to delete my account and that this now has unfortunate
consequences.

Hannes

>>>>> > > On Wed, Sep 21, 2011 at 11:58 AM, Rouven We�ling

Sam Moffatt

unread,
Oct 5, 2011, 5:10:49 AM10/5/11
to joomla-...@googlegroups.com
As the unfortunate volunteer who is now on the third occasion having
to spend time in the bowels of the JoomlaCode's database to personally
manage your account, would you kindly let me know where our stories
diverge?

Is it:
- the point where you were banned and posted anyway necessitating a
less honour bound system of technically limiting you instead of having
faith that you might respect the boundaries?
- or that you issued a legal threat to the project if something wasn't done?

You do however have the distinction as the user of JoomlaCode for whom
I have spent the most amount of time on. The only possible exception
is klas for whom I end up banning periodically when he creates a new
account to evade his ban again.

Sam Moffatt
http://pasamio.id.au

On Wed, Oct 5, 2011 at 1:14 AM, Hannes Papenberg

>>>>>>     >     > On Wed, Sep 21, 2011 at 11:58 AM, Rouven Weßling

brian teeman

unread,
Oct 5, 2011, 5:44:19 AM10/5/11
to joomla-...@googlegroups.com
Guys - this isn't relevant to this mailing list

Marius van Rijnsoever

unread,
Oct 5, 2011, 9:47:45 AM10/5/11
to joomla-...@googlegroups.com
Hi Hannes,

The JGrid class looks very promising. It surely simplifies the process
and makes its easier as is avoids mixing php code with html output.

Before:
https://github.com/joomla/joomla-cms/blob/master/administrator/components/com_users/views/users/tmpl/default.php
After:
https://github.com/Hackwar/joomla-cms/blob/jgrid/administrator/components/com_users/views/users/view.html.php


It does not remove or alter any core functions, it just adds a nifty
feature. Therefore there should be no issues at all getting this in
the Joomla core for the next release. (unlike your new router, which
adds radical new (and awesome) features, but therefore breaks the
default behaviour).

+1 vote by me to add these class.

Thanks, Marius

Hannes Papenberg

unread,
Oct 9, 2011, 6:46:31 AM10/9/11
to joomla-...@googlegroups.com
I've extended the changes that I did a bit and implemented JGrid both
for bluestork and hathor in the users view of com_users and its modal
view. You can see the code here:
https://github.com/Hackwar/joomla-cms/tree/jgrid

At least in this view, the differences between hathor and the default
output in the tables seem to be pretty small. At the same time, the
hathor output seems a bit more reasonable than the default output, so
maybe we should adopt the hathor code in the area of the tables. This
specifically means that a modal table has the additional class "modal"
and that column width are handled with classes instead of hardcoding
'width="25%"'. On the other hand, the pagination in hathor maybe should
be put into the footer of the table instead of having it outside of the
table. Besides that, there is a small typo in the modal layout of
hathor. The width class are written "width=25" instead of "width-25".

If the implementation of JGrid into 2.5 is accepted, I would like to try
to implement JGrid in all table layouts of com_users, com_categories and
com_content as a minimum goal, since I think these three extensions
would benefit the most of this little feature.

Hannes

Am 05.10.2011 02:43, schrieb Andrea Tarr at Tarr Consulting:
> The biggest issue we have with removing Hathor overrides is with the
> jump menu used for the filters and the pagination display number.
> Those are inaccessible for keyboard use which is why in Hathor you
> have to use the Submit button for the filters. Until that is solved,
> we'll need to keep the overrides.
>
> Andy

> *Andrea Tarr*
> *
> *
> *Tarr Consulting*
> www.tarrconsulting.com <http://www.tarrconsulting.com>


>
>
>
>
>
>
> On Oct 4, 2011, at 7:01 PM, elin wrote:
>
>> No one gets guarantees on feature acceptance. Since the work is in
>> the platform, you could perhaps work on one component at a time and
>> submit it for people to start testing (like what we are doing with
>> the JDatabasequery work). It does not have to be all or nothing, in
>> other words, for example start with weblinks as the simplest example.
>> That way extension developers can see how to use the API.
>> Personally, I would like to see us replace as many non accessible
>> elements in the current core layouts and default templates as
>> possible and in general move the Hathor work into the default. So
>> another possibility is to propose first a set of new overrides to
>> replace the Hathor overrides, assuming that JGrid meets the
>> accessibility standards and so on (I don't know enough about them to
>> evaluate that).
>>
>>
>>
>>
>> Elin
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Joomla! CMS Development" group.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msg/joomla-dev-cms/-/dBOHjL6R9rYJ.
>> To post to this group, send an email to

>> joomla-...@googlegroups.com <mailto:joomla-...@googlegroups.com>.


>> To unsubscribe from this group, send email to
>> joomla-dev-cm...@googlegroups.com

>> <mailto:joomla-dev-cm...@googlegroups.com>.


>> For more options, visit this group at
>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.

elin

unread,
Oct 9, 2011, 9:48:55 AM10/9/11
to joomla-...@googlegroups.com
Andrea can you tell us more about the button issue? Is this something you think is solvable? Or is it inherent in accessible design?  
Maybe there is someone who would like to take that on as a project if it is conceivably solvable. It would sure make things simpler.

Elin

Hannes Papenberg

unread,
Jan 15, 2012, 11:22:49 AM1/15/12
to joomla-...@googlegroups.com
Hi folks,
after some time I created a pull request to implement JGrid in a few
views of the CMS and also created a tracker item. Please check it out
here and discuss/approve:
https://github.com/joomla/joomla-cms/pull/23
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=27725

Hannes

Am 21.09.2011 20:58, schrieb Rouven We�ling:

Chad Windnagle

unread,
Jan 18, 2012, 7:56:50 PM1/18/12
to joomla-...@googlegroups.com
Hi Hannes:

I'm planning to write a blog post on using JGrid that will be  posted on developer.joomla.org. JGrid is a great feature for developers. 

I'm trying to see exactly how to use it. I know in your pull request you said that it was implemented in com_users. Do you know if that got put in the 2.5 beta2? I looked but I don't seem to see it in the code anywhere.

This my (undoubtly error-ridden) attempt to implement the class on a 11.4 platform app:

public function useJGrid() {
jimport('joomla.html.grid');
$myTable = new JGrid ;
$myTable->setTableOptions('width:100px;','false');
$myTable->addColumn("column 1");
$myTable->addColumn("column 2");
$myTable->addRow('width:50px' false;)
}

I know that setTableOptions is supposed to be passed an array. Maybe you can give me an idea what this would look like? 

-Chad


Regards,
Chad Windnagle
Fight SOPA


On Sun, Jan 15, 2012 at 11:22 AM, Hannes Papenberg <hack...@googlemail.com> wrote:
Hi folks,
after some time I created a pull request to implement JGrid in a few
views of the CMS and also created a tracker item. Please check it out
here and discuss/approve:
https://github.com/joomla/joomla-cms/pull/23
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=27725

Hannes

Am 21.09.2011 20:58, schrieb Rouven Weßling:
> Hi Hannes.
>
> On 21.09.2011, at 18:36, Hannes Papenberg wrote:
>
>> 3. Having all the standard work done in the class, we are simplifying
>> the layouts, resulting in the end in a common layout for all list views
>> that looks kinda like echo $filters; echo $table Changes to the layouts
>> would only have to be done once and would all work directly in all
>> components.
> This sound very interesting and could help make things, especially in the backend, more consistent. Without looking at your code I have one question and that is if it's possible for templates to change the markup and if so how much flexibility they have.
>
>> The question now is, if I should start converting the list views in
>> Joomla to using JGrid and if that all can be part of 2.5 already. Please
>> advice.
> I have no strong opinion in either direction but I'd like to warn that this will most likely break 3rd party admin templates. IMO not a deal breaker but something to be aware of.
>
> Best regards
> Rouven
>

Chad Windnagle

unread,
Jan 18, 2012, 8:26:40 PM1/18/12
to joomla-...@googlegroups.com
Update on this:

I've actually made a fair bit more progress:

public function useJGrid() {
jimport('joomla.html.grid');
$myTable = new JGrid;
$myattributes = array("width" => "100px", "border" => "1px solid #000");
$myTable->setTableOptions($myattributes,'false');
$myTable->addColumn("column 1");
$myTable->addColumn("column 2");
$myTable->addRow($myattributes, false);
$myTable->setRowCell("cell1", "mycontent");
$myTable->setRowCell("cell2", "mycontent");
return $myTable->toString();
}

Which is now returning actual HTML as a table for me. The one thing I can't seem to swing is to add rows and cell data.

-Chad

Regards,
Chad Windnagle
Fight SOPA


Chad Windnagle

unread,
Jan 18, 2012, 9:15:28 PM1/18/12
to joomla-...@googlegroups.com
Okay. Got it all figured out now finally! I found a great example here:


Thanks, and apologies for repeatedly hitting this mail list.

-Chad

Regards,
Chad Windnagle
Fight SOPA


Hannes Papenberg

unread,
Jan 19, 2012, 2:47:17 AM1/19/12
to joomla-...@googlegroups.com

You`re welcome. ;-)

Hannes Papenberg

unread,
Jan 19, 2012, 3:04:46 AM1/19/12
to joomla-...@googlegroups.com

To be a little bit more precise: the class is in joomla 2.5, but its not used anywhere. That is what the pull request is for.

Reply all
Reply to author
Forward
0 new messages