The use of specific Component User Tables

During our development of our Time sheet component we looked very closely at the use of specific component user tables. These are tables that are specific to a component, which are/can be very useful when there is a requirement to associate some specific criteria to one or more users. i.e We might wish to enable email sending only to specific users.  This could be achieved with the use of Joomla ACL controls but often this can be a little bit overkill especially when there are a number of different combinations involved. In these situations the number of ACL groups required could/would quickly get out of hand and require a lot more overhead in determining the result if user actions in the component. Such user tables are often automatically populated by a system plugin that would automatically add any newly registered Joomla users to the component user table and also maintain any changes that the user might make to their profile such as username or email address between the Joomla user table and the component user table.

One other use for a specific component user table would be where there is a requirement for specific ‘unregistered’ users. An example might be where the component was collecting details of users who requested information upon a specific topic by filling in a form upon the site front end, and at some later stage an administrator might process such requests from the details recorded in the component user table.

Generally component user tables work well in practice but there is one large downside, which is that there is (in all of the uses we have seen),  an explicit assumption that all Joomla users will or are required to make use of the Joomla component, which is not necessarily true.  A Joomla web site will probably have a number (often in the hundreds if not thousands) of users and if the site has a specific component installed that is used for example, by internal staff only, there is no need to have additional entries in the component users table for the non-staff members. In the case of our Timesheet component only certain of the site users would make use of the component so there is no need to have an entry in the component user table for every single one of the Joomla users.

This has resulted in our implementing a change to how Joomla users are integrated into the component user table. The former mechanism of having automatic user table update by the use of the system plugin was obviously not desirable,however we did want to synchronise any updates (and deletions).  Thus we have a need to introduce an optional parameter to the system plugin which will control whether new Joomla users are automatically added to the component user table.

With this in mind we have modified a few of our components, and are in the process of modifying a few others, so that the automatic addition of Joomla users to the component users table is a system plugin option. This change is relatively trivial, but there is an additional change required, which is to provide a mechanism so that users can manually added to the component users table by a site administrator when required, such as when new staff join the company..

The first component to use these mechanisms was our Timesheet component and we have now also added our Rialto (Classified Ads) component,  Obviously in the first of these we are only interested in providing the ability to create timesheets to our internal staff.  In the later component we may only have a select sub group of users who we may want to be able to create/manage their classified advertisements. We will also add that, yes we do also include the ability in the components to use Joomla ACL rules but this alone would not address the number of entries in the component users table and could well make the administration of ACL groups a lot more complex as mentioned earlier.

There is some additional code required but the benefits include a smaller component users table, with much clearer administrative visibility and control over who is using the specific  component.  It also provides the ability to have a simple test upon whether the register user in the front end has an entry in our component user table to control what specific front end views they may be presented with.

490 Hits

CSS: Text wrapping in a table cell. Part 2

CSS logoWe previously made an entry about long text strings overlapping table cells.  It was time to relook at the problem again after we saw a few more instances on our site.

The problem is quite common and has been mentioned in various articles upon the web for many years.  Solutions have ranged from the use of code to add extra spaces into the text fields, sometimes using ‘hidden’ characters, to various suggested CSS additions, many of which have browser dependencies.

This article on Stackoverflow summaries the suggestions quite adequately, but unfortunately didn’t provide a suitable solution.

Finally I discovered an article which describes the problem perfectly with examples. It is quite old (2007) but still holds true even today, with many revisions of browsers later.

In our case the final table cell was overlapping the right hand side menu and module displays, with the modules on top obscuring the table cell contents. We resolved it by using the suggestion in the article by changing to a fixed width table. Now the word-break could work.  It does mean that some of the other columns are slightly larger but it does produce a more professional output on the site.

This change will be implemented in latter releases of the Issue Tracker component.

Template Override

Whilst investigating this problem we had forgotten that we had implemented a CSS table override for the component so it is perhaps worth mentioning that here as well.  The CSS override is created by creating a file in the templates directory under template_name/media/com_issuetracker/css/ named issuetracker.css.  A copy of the distributed CSS file would serve as a starting point.  When changes are made to this file they take effect and override those in the media/com_issuetracker/css/issuetracker.css file.  This means that any changes you make would still apply even when/if the component is upgraded.  It is a convenient place to test out small CSS changes.

2302 Hits

Nested tables, MySQL and Joomla Smart Search.

b2ap3 icon joomlaWe have been looking at refining a finder plugin in Joomla which is accessing a nested MySQL table.  Nothing complex about that one would think.

However the desire was to expand out the different sub record titles into a single ‘title’ comprised of the individual sub record titles linked together offered a few ‘opportunities’ for want of a different word!

To explain further.  We have a classic nested table structure as follows:

Continue reading
1669 Hits

CSS: text wrapping in a table cell. word-wrap

The subject of wrapping text in a cell with CSS is reasonably well documented, and we recently investigated a specific case where the use of the standard ‘options/commands’ didn't seem to be having the desired effect. This was complicated by the fact that the target cell was a variable width.

The obvious commands are:

word-wrap  - which can take the one of two optional parameters:  ‘normal’ which will break words only at allowed break points; and ‘break-word’ which allows unbreakable words to be broken.

word-break – which has three possible values: ‘normal’ which breaks non-CJK scripts according to their own rules; ‘break-all’ where lines may break between any two characters for non-CJK scripts; ‘hyphenate’ where words may be broken at an appropriate hyphenation point.

Despite ‘playing’  with these the text was not breaking at the end of suitable values.

Continue reading
2184 Hits

Experiences with CSS and a table style

Whilst working on presenting a sample table style for our Issue Tracker component one particular colour combination was creating a few problems. The main problem was the colour of the links in the table header.  These would be used to sort the list and due to the choice of colour scheme the link colours were taking the settings from an earlier (in the tree)  DIV style.

This resulted in us temporarily shelving the table style until such time as we had to investigate further.  With the release of 1.3 of Issue Tracker we have now turned our attention back to the style sheet. The investigation was interesting and it is likely that others might benefit from our experiences hence the decision to make it a Blog post.

The resolution was to make use of the  !important declaration which been around since CSS1 but should still be used with caution.

Continue reading
1083 Hits

Custom CSS and DocBook XML documents

docimport-48We have previously mentioned using XML documents in DocBook format. We now turn our attention to the question of the format of the tables. A previous blog on DocBook table format mentioned the two types of  tables supported by DocBook, but not every document table necessarily has to be in the same format. We have an ‘in-house’ style used for some time and the desire was to retain a similar format with our web pages.

We are using a Joomla component named DocImport written by Nicholas K. Dionysopoulos and are very pleased with its behaviour even though it is still in an ‘alpha’ release form. A credit to the authors abilities. The component presents each web page with headers and footers which are using a ‘table style’ which does not display column separators. This is understandable since the standard format for tables is basic to put it bluntly. 

Continue reading
1339 Hits

DocBook XML tables

We have been studying  the DocBook DTD and in particular the table specifications.  There are two separate and distinct formats supported, the originals CALS format and the ‘newer’ HTML format since DocBook version 4.3. CALS is an SGML standard developed by the U.S. military, and their set of table tags was one of the first to be developed that included complex features for tables.

Some confusion was encountered since one source claimed that both table formats could not be used in the same document, whilst another source claimed that the two forms cannot be mixed within  the same definition, which makes more sense.

Later, because of widespread familiarity with HTML tables, DocBook added HTML table elements. Now you can use tr and td instead of row and entry in a table.  They cannot be mixed within one table. Also, the content of each table cell has to be valid DocBook, so you cannot usually just cut and paste an HTML table into your DocBook document. But the DTD does permit a document to contain both CALS tables and HTML tables. The tgroup element is the distinguishing characteristic between them. A CALS table requires a tgroup, and an HTML table does not permit one.

Continue reading
988 Hits
Go To Top

The Macrotone Consulting Web site would like to use cookies to store information on your computer, to improve our website. Cookies used for the essential operation of the site have already been set. To find out more about the cookies we use and how to delete them, see our Privacy Policy.

I accept cookies from this site.