Install XML for more than one version (1.5, 1.6, 1.7)
dan1dyoung
I an just testing my extensions on 1.6 ready for final testing after
Beta release and have one comment on the future of the XML file.
Currenty to have my extensions work on both 1.5 and 1.6 i have to
maintain 2 extensions as i have to put "<install version="1.5"
type="xxxx" group="xxxx">" in one and "<install version="1.6"
type="xxxx" group="xxxx">" in the other.
As i have got it this is the only difference between running on 1.5
Native and 1.6 for the extensions i have tested so far (Some slight
changes to suit both may be needed for some calls or use if
version=1.6 then else) and was wondering if we could do something
different to 1.6 while it is still in dev.
I am not sure how 1.5 works now with this line but if it just looks at
the first "<install version=" then we could leave 1.5 alone and just
change 1.6 to loop through more than one for a match, so as below:
XML File
"<install version="1.5" type="xxxx" group="xxxx">" Where Joomla 1.5
only looks at the first one (Must be first)
"<install version="1.6" type="xxxx" group="xxxx">" Where Joomla 1.6
and above loop through for a match to there version
"<install version="1.7" type="xxxx" group="xxxx">"
Maybe we could also then have certain if statements or scripts for the
install based on the version installing to allow for some changes
between versions for new database names for example.
Just an idea to keep development of extensions easier and so end users
just have one file for one function and the software does the work of
choosing the correct parts for the installing version.
Thanks
Dan
geeffland
component etc. to install in multiple versions. If you did it with
the multiple <install> tags then you could allow different files or
instructions to be executed during the install. So having Joomla loop
thru the <install> tags/nodes seems like a robust option to allowing
the component to install in multiple versions.
Andrew Eddie
Technically that will create invalid XML. You'd need to wrap them in
something like:
<installs type="xxxx" group="xxxx">
<install version="1.5">
</install>
<install version="1.6">
</install>
</install>
I can see why you are asking that but personally I would not recommend
trying to have smart components that autoswitch between using 1.5 and
1.6 technologies. It might seem like less work in the short term but,
in my experience in the long term it comes back to bite you. You will
also end up with a lot of unnecessary bloat when running on 1.6.
That's just my opinion though.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/30 dan1dyoung <dan...@dysolutions.co.uk>:
dan1dyoung
I agree with the valid XML part and the possible extra code to suit
both if it is required, just thought it would be useful for times like
i have now where the only thing difference between my 1.5 and 1.6
(Unless it changes after Beta) is the install part (Nothing else).
Thanks
Dan
On 29 Nov, 23:33, Andrew Eddie <mambob...@gmail.com> wrote:
> Hi Dan
>
> Technically that will create invalid XML. You'd need to wrap them in
> something like:
>
> <installs type="xxxx" group="xxxx">
> <install version="1.5">
> </install>
> <install version="1.6">
> </install>
> </install>
>
> I can see why you are asking that but personally I would not recommend
> trying to have smart components that autoswitch between using 1.5 and
> 1.6 technologies. It might seem like less work in the short term but,
> in my experience in the long term it comes back to bite you. You will
> also end up with a lot of unnecessary bloat when running on 1.6.
> That's just my opinion though.
>
> Regards,
>
> - Show quoted text -
Beat
On 30 Nov, 00:33, Andrew Eddie <mambob...@gmail.com> wrote:
> I can see why you are asking that but personally I would not recommend
> trying to have smart components that autoswitch between using 1.5 and
> 1.6 technologies. It might seem like less work in the short term but,
> in my experience in the long term it comes back to bite you. You will
> also end up with a lot of unnecessary bloat when running on 1.6.
> That's just my opinion though.
Thanks for your reply, that I understand. However, I respectfully
disagree:
It really depends on how you implement and maintain your extension.
Maintaining multiple versions of an extension for all versions and
CMSes can be a much larger hurdle than maintaining a single version
with a clean interface library/framework.
After the GPL debate and as a consequence of the previous core team
statements regarding that debate, many extensions developers have
chosen the library/framework approach, which provides btw many
benefits as well (for me one major one is that I have only one place
to change to workaround joomla bugs and regressions and to adapt to
new Joomla versions).
While I understand your approach and the reasons you want to rewrite
each component, ignoring the different approach of many extensions
developers is just pushing them away, and making their adaptations to
support Joomla 1.6 harder.
I would also like to be able to have a single installer, please add my
little vote in favor of XML files backwards compatibility (and
installer one in particular).
We have found a way to do it for Mambo + Joomla 1.0 + Joomla 1.5.
Being able to do it for 1.6 (and 1.0 and 1.7 and 2.0) too would make
our lives much easier in terms of maintenance and support.
E.g. the <files> lists don't have to be multiple and you don't need
multiple <install> sub-trees... a statement like:
<install version="1.5" compatibleversions="1.5,1.6,1.7" type="xxxx"
group="xxxx">
would already do it IF you don't change backwards compatibility of the
XML syntax.
But e.g. a new tag <version is="=1.6"> to include things specific in
the installer xml could just be fine, and would be ignored by previous
1.5 installer.
Also, please by all means, generally, don't break XML files
compatibility just for the eye's candy. E.g. <param> should continue
to work in addition of <field> also when 1.6 is released...
We are now 3 in here asking politely to think about universal
installers that are backwards compatible.
Please listen to your community of developers, and accept reasonable,
easy to implement requests, proposals and contributions, such as this
one.
I read that the above is only your own opinion, but as you are one of
main joomla core code decision-maker with trunk svn commit rights,
it's more than just your own opinion... ;-)
Looking forward,
Positively and respectfully,
Beat
Andrew Eddie
2009/12/1 Beat <bea...@gmail.com>:
>
> Hi Andrew,
>
> Thanks for your reply, that I understand. However, I respectfully
> disagree:
>
> It really depends on how you implement and maintain your extension.
When I say "that's just my opinion" I really mean it. It doesn't mean
I'm ignoring anyone's point of view (in fact I said I understand). I
was just casually relating my experience. It does not mean I have any
say in whether there can be support for it or not.
> Maintaining multiple versions of an extension for all versions and
> CMSes can be a much larger hurdle than maintaining a single version
> with a clean interface library/framework.
You'll note I use a framework approach as well ;)
> After the GPL debate and as a consequence of the previous core team
> statements regarding that debate, many extensions developers have
> chosen the library/framework approach, which provides btw many
> benefits as well (for me one major one is that I have only one place
> to change to workaround joomla bugs and regressions and to adapt to
> new Joomla versions).
That's great, but I'm not really sure how the license relates to your
choice of API. I don't see the correlation.
> While I understand your approach and the reasons you want to rewrite
> each component, ignoring the different approach of many extensions
> developers is just pushing them away, and making their adaptations to
> support Joomla 1.6 harder.
I will repeat, when I say I'm giving you an opinion I mean it. If
that way suits you then go for it, but for me personally, I've tried
and found problems with it. I do not take kindly to you suggesting
I'm ignoring people. You know me better than that.
> I would also like to be able to have a single installer, please add my
> little vote in favor of XML files backwards compatibility (and
> installer one in particular).
Vote has nothing to do with - just start playing with it. I don't
have any say in whether or not you can discuss this option :)
Conversely though, be open minded about alternative approaches as
well.
> We have found a way to do it for Mambo + Joomla 1.0 + Joomla 1.5.
That's great. Not my choice, but fantastic that you do that.
> Being able to do it for 1.6 (and 1.0 and 1.7 and 2.0) too would make
> our lives much easier in terms of maintenance and support.
For me it's not easier, but then I don't choose to support as many
versions. If you do, fantastic.
> E.g. the <files> lists don't have to be multiple and you don't need
> multiple <install> sub-trees... a statement like:
> <install version="1.5" compatibleversions="1.5,1.6,1.7" type="xxxx"
> group="xxxx">
> would already do it IF you don't change backwards compatibility of the
> XML syntax.
> But e.g. a new tag <version is="=1.6"> to include things specific in
> the installer xml could just be fine, and would be ignored by previous
> 1.5 installer.
>
> Also, please by all means, generally, don't break XML files
> compatibility just for the eye's candy. E.g. <param> should continue
> to work in addition of <field> also when 1.6 is released...
It's not just for eye candy. If you want to address that topic I
suggest you do another thread. However, you are going to have to deal
with the fact that new versions deprecate features and that's why I
think it's going to be hard for you to continue supporting from Mambo
to Joomla 1.x.
> We are now 3 in here asking politely to think about universal
> installers that are backwards compatible.
Awesome, that's 3 that can work on the code required.
> Please listen to your community of developers, and accept reasonable,
> easy to implement requests, proposals and contributions, such as this
> one.
Please don't assume I'm not listening but respect that I may choose to
do things differently.
> I read that the above is only your own opinion, but as you are one of
> main joomla core code decision-maker with trunk svn commit rights,
> it's more than just your own opinion... ;-)
No, it's just my opinion based on what I've found to be most efficient
for me. I am happy to share my philosophy if people want it but if
you want to do something different, and put the effort into it, that's
up to you. However, I do ask you take into account the big picture
and make sure you what you are doing makes sense and does not over
complicate the core just for the sake of you wanting to support Joomla
1.0. The project doesn't support that anymore so I think if you want
core changes to do that, you may be on your own.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
Sam Moffatt
mostly compatible with 1.6 and we can keep that going for the most
part. You can also write code in your custom install to handle
swapping stuff around if you need to, and perhaps write it as a
library to handle it in a generic way and contribute it back to the
community. The major change in 1.6 is that its 'extension' not
'install' because install is used in components later on so extension
is a much more generic name reflective of the item.
I'm not sure about supporting multiple install packages by abusing XML
is a good way. The installation system is in fact highly adaptable.
You can write your own custom installer adapter (I should know, I have
a few of my own) to support what you need. What I'd like to see is a
PECL style model where something gets stabilised externally and we
include it later. So what you can do is build a system to provide "fat
installers" for both 1.5, 1.6 and future releases. 1.6 has some better
support for this however you could create a fat installation adapter
that wrappers any other package type which then works out what you're
installing, picks up the right package and then spawns a new installer
instance and uses that. If it gets up and gets stable maybe we can
then consider about adding it to 1.5 and depending on how quickly you
work we might be able to slip it into 1.6 but you would have to get it
up, tested and stable in a relatively quick period of time.
So the bottom line is this:
- create a new project somewhere on JoomlaCode (or Google Code, or
SF) just somewhere open
- grab one of the existing installer adapters on 1.5 or 1.6 and
create a fat installer adapter (fat.php?)
- installer adapters subtly change between 1.5 and 1.6 in their
return value, i need to write that down somewhere (see below)
- get that fat adapter stable for 1.5 and 1.6 with a defined XML
installation format that works with both and reasonable test cases
- unit tests would be good
- get some sample packages using it
- you can distribute it without requiring it to be in the core and
the packages will work, until its in core its a dep of your install
but thats life.
Then I'll have to find some time to do a code review and be happy that
I'm happy it does everything it is required. I'd reasonably expect you
to take at least a month to do it properly if not a little bit more.
Before considering putting it into something we'd need to at least
have some reasonable examples of it as well as perhaps a quick demo
(similar to the installer samples I've been trying to do for 1.6) that
is small enough someone can pick up and modify for their own uses.
A quick note on the diff between 1.5 and 1.6, in 1.5 the return value
isn't really used beyond working or not working. In 1.6 the return
value for installs should be an extension ID, same deal I think for
updates/discover_installs, discover i think returns the number of
extensions that were discovered by the plugin (probably a nop for a
fat installer wrapper) or a list of extensions that were discovered
(can't remember, but again, probably nop) and uninstall is a boolean
(for both really). I wrote some basic doco up but I need to write more
(and have time, yes magic thing):
http://docs.joomla.org/Extension_Installer - copying the plugin
installer is probably the easiest one.
If you create a JoomlaCode project in the next half an hour (which is
about how long my battery is going to last), I'll even approve it for
you.
Cheers,
Sam Moffatt
http://pasamio.id.au
Beat
Not sure why things need to get that complicated to just add a
"versioncompatibility" tag to the installer ?
We are talking here about the main XML file of a component, of a
module or of a plugin. The one which is installed first.
The XML file doesn't need to be compatible with Joomla 1.0 and Mambo
(we're using a different XML file for them ;) ), but its basic tags
should be compatible with 1.5.
I mean, Joomla 1.6 doesn't need to accept 1.5 components, if that's
your wish, but 1.6 components which are compatible with 1.5 should be
accepted (provided the right attributes are set).
I've already built custom installers, which are quite powerful and
have shared them in CB 1.2, but those can execute only when the main
XML file is accepted.
All it needs is probably 2-5 lines of code in the XML <install> tag
version check. Don't think that opening a project on the forge and
write installer adapters is the way to go.
I'm seeing 2 simple ways to achieve single package:
a) <install version="1.5" compatiblewith="1.5,1.6" ... >
b) have joomla 1.6+ ignoring XML files where the <install
version="XXX"> tag is with XXX not 1.6, and searching in the next XML
file if it finds a version="1.6" file.
Happy to contribute the probably few lines of code for either or both
of those.
Just need the ok of whoever-has-the-power-to-decide-on-design-issues
first. My development pattern includes design before
implementation. :)
Best Regards,
Beat
>
> If you create a JoomlaCode project in the next half an hour (which is
> about how long my battery is going to last), I'll even approve it for
> you.
>
> Cheers,
>
> > 2009/12/1 Beat <beat...@gmail.com>: