New features for Joomla! 1.6???
CedricWalter
I would like to submit the following in Joomla 1.6
* A color picker, need this in many modules, components and this is
really missing in Joomla! panel overall (using http://moorainbow.woolly-sheep.net/#demos),
basically a new JParameter
* A Multi selector for category and section, can be new JElement or a
patch to existing ones. This should allow us developer to select many
categories and or sections, without forcing users to enter a list of
ID
* A patch to the HTML renderer of HEAD, to allow minifying at the core
level. There is many extensions already available (including one of me
named minify), but why doing this in a system plugin and rewriting
html or worse forcing the user to do it manually by editing php
+templates where a hook or a special renderer in joomla! core would be
easier (transparent). This would gives a huge performances boost, by
minimizing http requests
I would also let the option to the user to use a mootols from google
code instead of /joomla/system/..., this could be a new tab
performances in global configurations
What are chances that these patches get accepted, timeline? etc...
Thanks
Cedric
Hannes Papenberg
the goal of the Joomla project is to provide a lean, fast and flexible
framework to create (web)applications, mainly the Joomla CMS, which
again is meant to provide a basic web-content-management-system. The
rule of thumb in general is: If 99 out of 100 websites need it, it
should be in the core. If only 20 out of 100 need it, we don't add it.
Everything else is supposed to be handled through third party extensions.
Thus said, I don't think that Joomla needs a color picker. The
multi-selector for categories is already planned or even already
implemented and there is already a trigger to implement a minifier
(onAfterRender). It is possible to use a different javascript then the
one shipped with Joomla easily, too. So there is no need for changes there.
Hannes
> --
>
> 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.
>
>
>
>
CedricWalter
> Hi Cedric,
> the goal of the Joomla project is to provide a lean, fast and flexible
> framework to create (web)applications, mainly the Joomla CMS, which
> again is meant to provide a basic web-content-management-system. The
> rule of thumb in general is: If 99 out of 100 websites need it, it
> should be in the core. If only 20 out of 100 need it, we don't add it.
> Everything else is supposed to be handled through third party extensions.
I agree, keeping the core lean is always a good idea, but the color
picker is the same league as the calendar: you do not let user
entering 01.01.2010, but prefer an ajax calendar. So why letting them
enter #FF0056? Templates could benefit, modules, plugins and
components. This color picker is a standard html widget I expect from
a web framework, at the same level for me as panels, radio, calendar.
> Thus said, I don't think that Joomla needs a color picker. The
> multi-selector for categories is already planned or even already
> implemented
Not in joomla 1.6 trunk, i did an update and found it nowhere...this
is a standard features, Joomla! propose a single category/section
JElement, a multiple make sense when you want to display modules in
some but not all categories...
> and there is already a trigger to implement a minifier
> (onAfterRender).
Yes but the point is to remove unneeded parsing in 3rd party plugin,
the event onAfterRender force to go through the whole html to replace
links that are know in renderer array (Css and JS) . I propose to
provide a hook to override the HEAD renderer (I can hack the core but
this is not the point) or to propose an optimized renderer (ship with
core). For highly visited site, it make sense.
It is possible to use a different javascript then the
> one shipped with Joomla easily, too. So there is no need for changes there.
No you have to:
* hack the behavior class to not include the js from joomla.
* add manually google code mootools urls in template.
This is what I do on my site, and this is for me a basic optimization
features (offload asset). I agree that we can propose URL rewriting in
Joomla! htaccess, but this is another hack.
I already did hack the core (for securityimages), because of missing
events for Captcha, and I hate this as I have to maintain these
patches at every new release of Joomla!
Regards
Cédric
Wilco Jansen
- Implement CAPTCHA helpers for any form.
Regards, Wilco
CedricWalter
I provide patch for the core code since 2006 (Joomla 1.0) and 2008
(Joomla 1.5) for protecting contact, register, login, lost
password ...I did that instead of copying 99% of existing code in my
own component.
I would like to help in this area if not done nor started...as I have
a HUGE interest to avoid these hacks...
Cedric
On Dec 29, 11:05 pm, Wilco Jansen <jansen.wi...@gmail.com> wrote:
> There are other ways to implement captcha events without hacking the core,
> but it is good to know that in the original plan of
> 1.6<http://developer.joomla.org/coordinator-blog/292-feature-patches-for-...>,
> published in January, the following was planned:
>
> - Implement CAPTCHA helpers for any form.
>
> Hope I am correct, this option has not yet been implemented in the current
> 1.6 trunk. Anything to mention on the status of this planned feature?
>
> Regards, Wilco
> > joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
Andrew Eddie
Regards
Andrew Eddie
> --
>
> 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.
>
>
>
--
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
CedricWalter
I will send it later today, I am now starting development...
Regards
Cedric
On Dec 29, 11:36 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> I'd be interested in seeing your patch for the colour picker.
>
> Regards
> Andrew Eddie
>
>
>
>
>
> On Wednesday, December 30, 2009, CedricWalter <cedric.wal...@gmail.com> wrote:
> > Hi all
>
> > I would like to submit the following in Joomla 1.6
>
> > * A color picker, need this in many modules, components and this is
> > really missing in Joomla! panel overall (usinghttp://moorainbow.woolly-sheep.net/#demos),
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
Jan (Phoca)
The advantage of Joomla! framework is, it is great extensible. So
making Color Picker Parameter (with help of some external Javascript
library) can be made simply and fast.
E.g. in 1.5 (I hope it will be the same in 1.6):
Copy standard parameter - text field, rename it and paste it into e.g.
elements folder (extend the JElement class) and add:
JHTML::stylesheet( 'colorpicker.css', 'path_to_css' );// load CSS for
the Picker
$document->addScript(JURI::base(true).'path_to_js/colorpicker.js');//
load Javascript for the Picker
and:
$html .= '<span style="margin-left:10px" onclick="javascript - open
the color picker with sending id parameter (id of the form field)"
class="color picker class">' . JText::_('Pick color') . '</span>';//
create a button for opening the Picker
after the text field.
So this can be made in seconds, in fact all possible parameters can be
done this way and the Joomla! core code will be not so large.
Jan
> > Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla developer
CedricWalter
But then why not removing calendar from core? and geshi (there is so
many 3rd party prettifier)
I know how to do this in in my own component, module, plugins but the
fact is that I have to duplicate the code across all these
components...and every 3rd party developer has to do the same
By the way the size of core is NOT relevant, continuous build and
regression testing is. It's not really important how big a framework
is, as long as test cases run often (fail early and reveal issues),
and code coverage is high. Continuous build and regression testing
(unit test, functional test) help you maintain bigger software with
confidence/less testing time/sometimes less developers. That the next
big thing for Joomla! to happen...Trying to keep something lean is
just a workaround, adding new functionalities require code...that
introduce new bugs and require maintenance efforts.
I remember that WikiPedia has made the step one year ago (CI and unit
tests)
The patch is developped, only persisting data in field is not working
(look tomorrow at it)
In html
<?php
JHtmlBehavior::colorpicker('myRainbow');
echo JHtml::_('colorpicker.colorpicker', 'myRainbow', 'true');
?>
in module xml
<field
name="color2"
id="color2"
type="colorpicker"
default=""
label="color test in module"
description="Color test" />
12 new files (css, js, images)
3 files changed
Cedric
> > > Andrew Eddiehttp://www.theartofjoomla.com-theart of becoming a Joomla developer
Paladin
On Dec 29, 2:35 pm, CedricWalter <cedric.wal...@gmail.com> wrote:
> I agree, keeping the core lean is always a good idea, but the color
> picker is the same league as the calendar: you do not let user
> entering 01.01.2010, but prefer an ajax calendar.
Just a thought: I wouldn't get too wedded to any date entry system in
core, since with HTML5 that functionality will be in the browser
itself. (Check current shipping version of Opera for one
implementation of it; both Mozilla and Webkit have it in their bug
tree right now.)
Paladin
as well. For example, this bug from the webkit tree:
https://bugs.webkit.org/show_bug.cgi?id=28966
CedricWalter
custom code with confidence. But adoption of html5 will at least take
some years, and old browser wont disapear so fast.
CedricWalter
HTML5 also defines <input type="color">, which lets you pick a color
and returns the color’s hexadecimal representation. No browser
supports it yet, which is a shame, because I’ve always loved the Mac
OS color picker. Maybe someday.
Date, email will be also supported...
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html
On Dec 31, 6:28 am, Paladin <arlen.wal...@gmail.com> wrote:
Chris Davenport
Chris.
Paladin
On Dec 31, 4:16 am, Chris Davenport <chris.davenp...@joomla.org>
wrote:
> Although it should be noted that HTML5 will only support the Gregorian
> calendar.
It supports the international standard (ISO 8601). Other calendars can
easily be derived from that. Or are you seriously suggesting that a
tiny fraction (is it even as much as 0.01%?) of cases justifies the
establishment and maintenance of a separate calendar system in core,
rather than letting conversions be handled by a plugin for those
needing it?
IE will, of course, be the last to support HTML5, but since we know
that's where everyone (even Microsoft) is headed, we may as well start
in that direction now, so we can be ready when it happens, instead of
lagging years behind the curve, like the tableless templating system
(to name one example) was. Given the time it may take, we may still be
late to the party as it is.
Paladin
On Dec 29, 1:50 pm, CedricWalter <cedric.wal...@gmail.com> wrote:
> I would also let the option to the user to use a mootols from google
> code instead of /joomla/system/..., this could be a new tab
> performances in global configurations
While I'm on this thread, I'd like to +1 this, with a twist: Allow a
third alternative, essentially a "write-in" for the source of the
files. That way, if one is using a CDN, the js could be sourced there,
as well.
Personally, I doubt I'd use that alternative, but I *know* I'd use the
google one. Providing the server is up to the load, letting multiple
sites pull common files from the same location will speed up *every*
site in the Joomla world.
Mitch Pirtle
++ on this idea, as the last 5 Joomla-powered sites I've launched all
used CDNs. They all happened to use only jQuery or a recent mootools
on the front end, so it was easy to do manually... But I can imagine
there are other sites using the provided mootools that could use this
feature for sure. Smart!
-- Mitch
Chris Davenport
It supports the international standard (ISO 8601). Other calendars can
easily be derived from that. Or are you seriously suggesting that a
tiny fraction (is it even as much as 0.01%?) of cases justifies the
establishment and maintenance of a separate calendar system in core,
rather than letting conversions be handled by a plugin for those
needing it?
I was merely pointing out that we cannot rely on HTML5 to handle all our calendar requirements, even if all browsers were to suddenly support it. This is because the Joomla community is much wider than just those people using the Gregorian calendar, in the same way that it is much wider than just those people who happen to speak some variation of English. We support non-English languages and we support non-Gregorian calendars for the same reason. If that is via the current system, or via some future method is immaterial, so long as we continue to support some sort of mechanism to achieve it. The move to HTML5 does not absolve us of the need to provide that support because HTML5 only addresses the Gregorian calendar.
But this seems to be getting way off topic.
Chris.
CedricWalter
Color picker SVN patch, made in eclipse PDT
Screenshots
http://www.waltercedric.com/download/colorpicker.banner.module.png
http://www.waltercedric.com/download/colorpicker.global.configuration.png
Download
* file at http://www.waltercedric.com/download/colorpicker.joomla1.6.trunk.patch
* Apply on joomla 1.6 trunk
I did modify just for the sake of example (should not be part of the
patch but provide real usage example)
* the banner module administrator panel
* The global configuration administrator panel
Happy new Year, less than 4 hours in France till midnight...
Cedric
On Dec 31, 7:42 pm, Chris Davenport <chris.davenp...@joomla.org>
wrote:
> 2009/12/31 Paladin <arlen.wal...@gmail.com>
Steven Pignataro
of WYSIWYG Editors - it is part of various other things as well.
Having it be part of the core would be kind of pointless in my
opinion. I manage 100's of websites on a daily basis and see no need
for it. The calendar addition is a necessity as it is used all the
time to manage the times of posting of your articles and many other
aspects. Color picker - I don't see a demand or a dire need of it.
I am going to have to agree with Hannes on this one.
Kindest regards,
--Steven Pignataro
Anthony McLin
If you want this to not be part of the core, then the core should provide a way to easily add additional field types that can be used throughout Joomla. Currently that's not possible without modifying core files that get overridden with updates.
I am really confused on why a color picker is even needed. It is part of WYSIWYG Editors - it is part of various other things as well. Having it be part of the core would be kind of pointless in my opinion. I manage 100's of websites on a daily basis and see no need for it. The calendar addition is a necessity as it is used all the time to manage the times of posting of your articles and many other aspects. Color picker - I don't see a demand or a dire need of it. I am going to have to agree with Hannes on this one. Kindest regards, --Steven Pignataro -- 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.
Anthony McLin
Senior Web Developer
amc...@kaadesigngroup.com
T 310.821.1400 F 310.821.1440
KAA Design Group, Inc.
4201 Redwood Avenue, Los Angeles, CA 90066
Architecture | Landscape | Brand Experience | Interiors
www.kaadesigngroup.com
Flip
Well as a blind site owner I can tell you it would be nice to have a
dropdown color picker that has them done in textural format. that way
those of us that are blind or color-blind would have just a bit of an
easier time of setting a color when needed any where within the
backend of Joomla.
TNX Flip
The Blind Ham
> > For more options, visit this group athttp://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
> --
> Anthony McLin
> Senior Web Developer
> amc...@kaadesigngroup.com
> T 310.821.1400 F 310.821.1440
>
> KAA Design Group, Inc.
> 4201 Redwood Avenue, Los Angeles, CA 90066
> Architecture | Landscape | Brand Experience | Interiorswww.kaadesigngroup.com- Hide quoted text -
>
> - Show quoted text -
Sam Moffatt
standard colour picker JParam item for use with any Joomla! site and
it wouldn't be touched by any core updates or deleted in any way. No
need to modify any existing files, just create a new element and make
it so. You can then distribute it either as a part of ones extension
or build something to install it somewhere (plugin or even in the core
location if you really want). Then it would work with any plugin,
template or module params in addition to being accessible to any
component that wishes as well.
Sam Moffatt
http://pasamio.id.au
Hannes Papenberg
create your field types and point to those extra files in your form XML.
See com_content for an example.
Hannes
Pierre Gazzola
jos_ extension for database
and just have
"you must enter a user table"
This would help new user from choosing jos_ as default.
> >> For more options, visit this group athttp://groups.google.com/group/joomla-dev-cms?hl=en-GB.