Hi all, with HTML5 the frame-elements will die. It will probably take some years before the browser-support of HTML4 will stop, but still. Are there any alternative implementations for the Zope2-ZMI? There is a package zmi.core in the Zope-svn, but except some links to other packages there is nothing in it. Is the package alive and what's the targeted platform: Zope2, BlueBream, grok? -Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Gross wrote:
Hi all,
with HTML5 the frame-elements will die. It will probably take some years before the browser-support of HTML4 will stop, but still. Are there any alternative implementations for the Zope2-ZMI? Get the frame-less ZMI by using /manage_main and the frame problem is solved. Yes, you lose the treeview but I actually never used it in my whole Zope life.
Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktpeOwACgkQCJIWIbr9KYxXQQCfZPrzqRwv4wfFPO//8CjMuior HzQAoK5Nnlyi+29ksm0kU8FkR4mi3mlc =Bixm -----END PGP SIGNATURE-----
with HTML5 the frame-elements will die. It will probably take some years before the browser-support of HTML4 will stop, but still. Are there any alternative implementations for the Zope2-ZMI?
This is such a minor thing that if we do ever get to a stage where we're having to get rid of the frames it would just be a patch. I never use frames in the ZMI myself, I just hit manage_main Matt
On Wed, Feb 3, 2010 at 2:20 PM, Tom Gross <itconsense@gmail.com> wrote:
with HTML5 the frame-elements will die. It will probably take some years before the browser-support of HTML4 will stop, but still. Are there any alternative implementations for the Zope2-ZMI?
I'd very much expect the general purpose ZMI to vanish long before the first browsers stop supporting HTML4. If they'll ever do that, it will probably be another 10 years or more. I doubt anyone can tell what Zope 2.20 will look like or if it will exist at all ;-) Hanno
On 02/03/2010 02:45 PM, Hanno Schlichting wrote:
On Wed, Feb 3, 2010 at 2:20 PM, Tom Gross <itconsense@gmail.com> wrote:
with HTML5 the frame-elements will die. It will probably take some years before the browser-support of HTML4 will stop, but still. Are there any alternative implementations for the Zope2-ZMI?
I'd very much expect the general purpose ZMI to vanish long before the first browsers stop supporting HTML4. If they'll ever do that, it will probably be another 10 years or more. I doubt anyone can tell what Zope 2.20 will look like or if it will exist at all ;-)
Zope 2.20 will probably use Twitter as the ZMI ... SCNR -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hanno Schlichting wrote:
On Wed, Feb 3, 2010 at 2:20 PM, Tom Gross <itconsense@gmail.com> wrote:
with HTML5 the frame-elements will die. It will probably take some years before the browser-support of HTML4 will stop, but still. Are there any alternative implementations for the Zope2-ZMI?
I'd very much expect the general purpose ZMI to vanish long before the first browsers stop supporting HTML4. If they'll ever do that, it will probably be another 10 years or more. I doubt anyone can tell what Zope 2.20 will look like or if it will exist at all ;-)
Hanno
Hello Probably at this point of the conversation is the right moment to ask if it would make sense to improve Zope2's ZMI, removing frames and perhaps DTML code and probably removing all the dtml from zope2. Kind Regards r. -- http://robertoallende.com
Hi, On Thu, 04 Feb 2010 00:59:52 -0300 Roberto Allende <rover@menttes.com> wrote: (snip)
Probably at this point of the conversation is the right moment to ask if it would make sense to improve Zope2's ZMI, removing frames and perhaps DTML code and probably removing all the dtml from zope2.
I'd say that removing all the dtml from zope2 is too much. I know that there are many web sites which have used dtml for a long time. And also dtml works quite well without any serious problems. Regards, -- Yusei TAHARA <yusei@domen.cx>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yusei TAHARA wrote:
On Thu, 04 Feb 2010 00:59:52 -0300 Roberto Allende <rover@menttes.com> wrote: (snip)
Probably at this point of the conversation is the right moment to ask if it would make sense to improve Zope2's ZMI, removing frames and perhaps DTML code and probably removing all the dtml from zope2.
I'd say that removing all the dtml from zope2 is too much. I know that there are many web sites which have used dtml for a long time. And also dtml works quite well without any serious problems.
I think perhaps Robert meant to say that Zope2 would[ no longer use DTML for any part of the ZMI, rather than removing the code which allows users applications to use DTML. I would favor the first alternative (but likely wouldn't put any effort into it). I would be opposed to ripping out DTML support for applications, however. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktqugEACgkQ+gerLs4ltQ4qZwCcD7y442HqSCg9fbiN8ElDbyv2 9nsAnj2NhZMBbp/uIp4rwzXxAGoIT3sz =oS8z -----END PGP SIGNATURE-----
Am 04.02.2010, 13:13 Uhr, schrieb Tres Seaver <tseaver@palladion.com>:
I think perhaps Robert meant to say that Zope2 would[ no longer use DTML for any part of the ZMI, rather than removing the code which allows users applications to use DTML.
This is something I would like to contribute to as it matches my skillset and interests pretty well. From the responses so far it seems that most people are so used to the ZMI that no change feels necessary and, let's face it, it works well enough. However, for new people coming to Zope the 1990nish of it is a bit off-putting: we've got all this cool technology underneath but you wouldn't believe it when you look at it. And I don't think much is required beyond dropping frames, the table-based layout using PageTemplates rather than DTML. I have an open ticket on much the same for CMFDefault which is where I will start from (from the point of view of separating markup from layout). But my work rate isn't brilliant so it would be good to have a sparring partner or two. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
On 2010-02-04, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
Am 04.02.2010, 13:13 Uhr, schrieb Tres Seaver <tseaver@palladion.com>:
I think perhaps Robert meant to say that Zope2 would[ no longer use DTML for any part of the ZMI, rather than removing the code which allows users applications to use DTML.
This is something I would like to contribute to as it matches my skillset and interests pretty well. From the responses so far it seems that most people are so used to the ZMI that no change feels necessary and, let's face it, it works well enough. However, for new people coming to Zope the 1990nish of it is a bit off-putting: we've got all this cool technology underneath but you wouldn't believe it when you look at it. And I don't think much is required beyond dropping frames, the table-based layout using PageTemplates rather than DTML. I have an open ticket on much the same for CMFDefault which is where I will start from (from the point of view of separating markup from layout). But my work rate isn't brilliant so it would be good to have a sparring partner or two.
+1, "works fine as is" or "will be dead before long" are not the best approaches IMO, factoring out the ZMI functionality in to something that folks can maintain and contribute to in the future if they want to, is.
Charlie
-- Alex Clark · http://aclark.net Practical Plone 3 · http://tinyurl.com/practical-plone
On 02/04/2010 10:35 PM, Alex Clark wrote:
On 2010-02-04, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
Am 04.02.2010, 13:13 Uhr, schrieb Tres Seaver <tseaver@palladion.com>:
I think perhaps Robert meant to say that Zope2 would[ no longer use DTML for any part of the ZMI, rather than removing the code which allows users applications to use DTML.
This is something I would like to contribute to as it matches my skillset and interests pretty well. From the responses so far it seems that most people are so used to the ZMI that no change feels necessary and, let's face it, it works well enough. However, for new people coming to Zope the 1990nish of it is a bit off-putting: we've got all this cool technology underneath but you wouldn't believe it when you look at it. And I don't think much is required beyond dropping frames, the table-based layout using PageTemplates rather than DTML. I have an open ticket on much the same for CMFDefault which is where I will start from (from the point of view of separating markup from layout). But my work rate isn't brilliant so it would be good to have a sparring partner or two.
+1, "works fine as is" or "will be dead before long" are not the best approaches IMO, factoring out the ZMI functionality in to something that folks can maintain and contribute to in the future if they want to, is.
Right. It does work as it is and as always we need to pay attention to keep things working. One chance I also see where improvements could happen is that packages might be able to provide UI components that get re-used within the various frameworks. Just a quick thought from my side, though. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
On Thu, Feb 4, 2010 at 14:48, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
This is something I would like to contribute to as it matches my skillset and interests pretty well. From the responses so far it seems that most people are so used to the ZMI that no change feels necessary and, let's face it, it works well enough. However, for new people coming to Zope the 1990nish of it is a bit off-putting: we've got all this cool technology underneath but you wouldn't believe it when you look at it.
Well, getting and iframe implementation with some really nice looking CSS would be cool, indeed. I don't even think you need to get rid of DTML for that. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro wrote:
On Thu, Feb 4, 2010 at 14:48, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
This is something I would like to contribute to as it matches my skillset and interests pretty well. From the responses so far it seems that most people are so used to the ZMI that no change feels necessary and, let's face it, it works well enough. However, for new people coming to Zope the 1990nish of it is a bit off-putting: we've got all this cool technology underneath but you wouldn't believe it when you look at it.
Well, getting and iframe implementation with some really nice looking CSS would be cool, indeed. I don't even think you need to get rid of DTML for that.
I agree. I was asking for 2 different things: One to improve ZMI and the other one about DTML. There's not much to speak about ZMI because we should just do it, in particular i'm interested do smt like that, so i could work with Charlie Clark and any other person interested, until we've something to show, then ask for feedback and so on. Regarding DTML... i wonder if it dtml purpose doesn't overlap with tal/metal or even viewlets. If that's the case we wouldn't provide 'One-- and preferably only one --obvious way to do it' and for non Dutch newbies :P is kinda confusing because end up with situations like 'you've to learn it but you won't use in-real-projects'. So, wouldn't make sense to have DTML in an separated component and make its use optional ?. No big deal, I'm just curious what do you think about it and it is an excuse to ask about existing ways to handle stuff like that. Kind Regards r. -- Let's promote Plone Worldwide: http://worldploneday.org - April 28th 2010.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roberto Allende wrote:
Regarding DTML... i wonder if it dtml purpose doesn't overlap with tal/metal or even viewlets. If that's the case we wouldn't provide 'One-- and preferably only one --obvious way to do it' and for non Dutch newbies :P is kinda confusing because end up with situations like 'you've to learn it but you won't use in-real-projects'.
You don't need to learn DTML at all to work with Zope2 these days, unless you want to use ZSQL methods, which still rely on it for generating dynamic SQL. I haven't written a line of "new" DTML-as-presentation-markup in Zope for about nine years now.
So, wouldn't make sense to have DTML in an separated component and make its use optional ?.
Its use is already optional. There is relatively no cost to leaving it in the core, and a substantial downside (useless backward-compatibility breakage). I'm fine with the goal of removing the *use* of DTML within the ZMI as part of implementing a future-proofed replacement, but totally against the idea of ripping it out of the core. My opinion is also shaped by my experience of trying to break out the pieces of Zope2 into separate eggs, like the Acquisition / ExtensionClass / DateTime etc. eggs: there is too much low-level coupling of the DocumentTemplate code to other parts of the codebase to make that easy, even assuming it were desirable. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkttE/kACgkQ+gerLs4ltQ5/8wCbB3goYRSJK2VhGfvnqLYBRpHb KyMAoLLXAr0JApHtJTRF97AF2vKHXLBJ =6Z91 -----END PGP SIGNATURE-----
Am 05.02.2010, 19:29 Uhr, schrieb Roberto Allende <rover@menttes.com>:
Regarding DTML... i wonder if it dtml purpose doesn't overlap with tal/metal or even viewlets. If that's the case we wouldn't provide 'One-- and preferably only one --obvious way to do it' and for non Dutch newbies is kinda confusing because end up with situations like 'you've to learn it but you won't use in-real-projects'.
Yes, DTML does overlap with ZPT and subsequent stuff. I'm in total agreement about being able to hold up the ZMI as an example of how Zope follows it own best practices. As Tres says removing DTML entirely from the code base would bring little benefit at considerable cost. However, I assume that once major consumers of DTML such as the ZMI and ZSQL were migrated it might become easier to refactor code to make DTML optional in time. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Charlie Clark wrote:
Am 05.02.2010, 19:29 Uhr, schrieb Roberto Allende <rover@menttes.com>:
Regarding DTML... i wonder if it dtml purpose doesn't overlap with tal/metal or even viewlets. If that's the case we wouldn't provide 'One-- and preferably only one --obvious way to do it' and for non Dutch newbies is kinda confusing because end up with situations like 'you've to learn it but you won't use in-real-projects'.
Yes, DTML does overlap with ZPT and subsequent stuff. I'm in total agreement about being able to hold up the ZMI as an example of how Zope follows it own best practices. As Tres says removing DTML entirely from the code base would bring little benefit at considerable cost. However, I assume that once major consumers of DTML such as the ZMI and ZSQL were migrated it might become easier to refactor code to make DTML optional in time.
You aren't ever going to get ZSQL "migrated" to use ZPT. ZPT is a really poor fit for "non-markup" templates like SQL. Folks writing "modern" apps tend to favor non-dynamic SQL anyway (using "placeholder variables") and so would just not use ZSQL. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktt15QACgkQ+gerLs4ltQ7tOACfbcVIM4vkZqNfrrQHj1ebJ8ki xm0AoLal356LtLFCkMC008vpTDI4DZTv =BSUZ -----END PGP SIGNATURE-----
Am 06.02.2010, 21:56 Uhr, schrieb Tres Seaver <tseaver@palladion.com>:
You aren't ever going to get ZSQL "migrated" to use ZPT. ZPT is a really poor fit for "non-markup" templates like SQL. Folks writing "modern" apps tend to favor non-dynamic SQL anyway (using "placeholder variables") and so would just not use ZSQL.
Sorry, I didn't mean to imply that. I would like an alternative to DTML for ZSQL which would generate SQL with the appropriate placeholders and some minimal templating logic. But that would be a different project. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Charlie Clark wrote:
Am 06.02.2010, 21:56 Uhr, schrieb Tres Seaver <tseaver@palladion.com>:
You aren't ever going to get ZSQL "migrated" to use ZPT. ZPT is a really poor fit for "non-markup" templates like SQL. Folks writing "modern" apps tend to favor non-dynamic SQL anyway (using "placeholder variables") and so would just not use ZSQL.
Sorry, I didn't mean to imply that. I would like an alternative to DTML for ZSQL which would generate SQL with the appropriate placeholders and some minimal templating logic. But that would be a different project.
Why do you want to write new apps on top of ZSQL? The only thing that is more disgusting than writing SQL code is generating SQL code with DTML. Sorry, but we are in the ORM world and using SQLAlchemy & friends is the much nicer and smoother way doing SQL related programming nowadays. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktu9pEACgkQCJIWIbr9KYxQOwCgvKV+Le8GP6I9DYU8BvZowbY4 +O8AnjPkDu3wSM8jHoZJViBN/hku9xWx =MlKL -----END PGP SIGNATURE-----
Am 07.02.2010, 18:21 Uhr, schrieb Andreas Jung <lists@zopyx.com>:
Why do you want to write new apps on top of ZSQL? The only thing that is more disgusting than writing SQL code is generating SQL code with DTML. Sorry, but we are in the ORM world and using SQLAlchemy & friends is the much nicer and smoother way doing SQL related programming nowadays.
I don't mind writing SQL and I think it has it's place in the world. That doesn't mean that people shouldn't use SQL generators such as SQLAlchemy and Storm and I agree that this now the most common approach. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote:
Charlie Clark wrote:
Am 06.02.2010, 21:56 Uhr, schrieb Tres Seaver <tseaver@palladion.com>:
You aren't ever going to get ZSQL "migrated" to use ZPT. ZPT is a really poor fit for "non-markup" templates like SQL. Folks writing "modern" apps tend to favor non-dynamic SQL anyway (using "placeholder variables") and so would just not use ZSQL. Sorry, I didn't mean to imply that. I would like an alternative to DTML for ZSQL which would generate SQL with the appropriate placeholders and some minimal templating logic. But that would be a different project.
Why do you want to write new apps on top of ZSQL? The only thing that is more disgusting than writing SQL code is generating SQL code with DTML. Sorry, but we are in the ORM world and using SQLAlchemy & friends is the much nicer and smoother way doing SQL related programming nowadays.
Andreas, you need to back off on the soapbox stuff. Not everybody likes ORMs, and they do have their downsides: I write SQL from scratch for the same reason the "old timers" hand assembled performance-critical bits of code, rather than using a C compiler: I believe (and still find it to be so) that the schemas and querires I hand tune out-perform the ORMs significantly for the problems I solve with RDBMSes. But I don't use them for "normal" apps: my typical applications have hundreds of thousands to millions or tens of millions of records in some tables. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktvepMACgkQ+gerLs4ltQ5ZnQCfbReeYlIOc3zZ0G31s0LlLzK5 /2UAn2q9ylYmj1TaLgkkNgknFm2e9siu =tRnd -----END PGP SIGNATURE-----
Hello, On Fri, 05 Feb 2010 15:29:03 -0300 Roberto Allende <rover@menttes.com> wrote: (snip)
Regarding DTML... i wonder if it dtml purpose doesn't overlap with tal/metal or even viewlets. If that's the case we wouldn't provide 'One-- and preferably only one --obvious way to do it' and for non Dutch newbies :P is kinda confusing because end up with situations like 'you've to learn it but you won't use in-real-projects'.
So, wouldn't make sense to have DTML in an separated component and make its use optional ?.
DTML is still very useful if we make non-xml stuff like SQL, CSS, JavaScript etc. And I have used it in many real projects for about 7 years. If there is something(online document?) which make new users confused, it would be better to fix it. ZPT is useful to generate xml/html documents, DTML is useful to generate non-xml documents. Regards, -- Yusei TAHARA <yusei@domen.cx>
Am 05.02.2010, 15:43 Uhr, schrieb Lennart Regebro <regebro@gmail.com>:
Well, getting and iframe implementation with some really nice looking CSS would be cool, indeed. I don't even think you need to get rid of DTML for that.
I'd prefer to do without frames altogether and, to be honest, I don't know why they've been kept in the specification. Presumably because in spite of all the associated problems (a client is pondering the use of an https iframe in an http page) they can bring a quick win without any "clever" server side stuff. Unfortunately you can't just add a dash of CSS to the rest. Migrating from DTML to ZPT would add weight to the "dog food" argument and should be fairly straightforward. ZPT came on the scene shortly after I started playing with Zope and is one of the biggest reasons for me sticking with it. The ZMI is probably the last big dependent of DTML in Zope 2 so it would be nice to be able to remove that dependency for Zope 2. On a related issue that is close to my heart: ZSQL. I'm sure I read of a related template (Smart Templates?) that would allow for minimal logic for SQL (I never use the SQL specific extensions to DTML apart from sqlvar) and similar languages but for the life of me I have not been able to find a trace of this. Did I imagine it? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
On 2010-02-06, at 1257, Charlie Clark wrote:
Migrating from DTML to ZPT would add weight to the "dog food" argument and should be fairly straightforward. ZPT came on the scene shortly after I started playing with Zope and is one of the biggest reasons for me sticking with it. The ZMI is probably the last big dependent of DTML in Zope 2 so it would be nice to be able to remove that dependency for Zope 2.
It seems like a lot of work for no gain. I can think of a couple of examples where DTML templates are monkey-patched in Plone and none of those are anything particularly vital. DTML works for the ZMI, new pages can be written in ZPT, why bother going back and changing them all? I mean, how often do you really need to do maintenance on the security form, for example? Matt
Am 06.02.2010, 15:21 Uhr, schrieb Matthew Wilkes <matthew@matthewwilkes.co.uk>:
It seems like a lot of work for no gain. I can think of a couple of examples where DTML templates are monkey-patched in Plone and none of those are anything particularly vital. DTML works for the ZMI, new pages can be written in ZPT, why bother going back and changing them all? I mean, how often do you really need to do maintenance on the security form, for example?
The reason for doing the work is not functional but aesthetical. This doesn't make it any less valid. Yes, it's a lot of work and yes I'm not a fast worker. But it is clearly definable and could best be done in two steps: 1) Move to a more recent version of HTML (HTML 5 without the new tags), CSS 2.1 based layout and iFrames for containment and use ZPT instead of DTML 2) Replace frames with aysnchronous communication Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
Charlie Clark wrote:
Am 06.02.2010, 15:21 Uhr, schrieb Matthew Wilkes <matthew@matthewwilkes.co.uk>:
It seems like a lot of work for no gain. I can think of a couple of examples where DTML templates are monkey-patched in Plone and none of those are anything particularly vital. DTML works for the ZMI, new pages can be written in ZPT, why bother going back and changing them all? I mean, how often do you really need to do maintenance on the security form, for example?
The reason for doing the work is not functional but aesthetical. This doesn't make it any less valid. Yes, it's a lot of work and yes I'm not a fast worker. But it is clearly definable and could best be done in two steps:
If the reason is entirely aesthetic, please consider that there is a ton of documentation out there, including books in print, which refers to the existing UI that's been in place for years and years. Changing it purely for aesthetic reasons would probably do more harm than good, and confuse a lot of users. I don't think the ZMI is particularly pretty, and it has various usability issues. Maybe addressing those would make a change worthwhile. That would involve some actual analysis and a process of design, not ad-hoc changes. Small changes like improving some of the graphics, or maybe replacing the current frameset with something more modern that still retains the same basic UI metaphor could also be worthwhile. This is far from the most pressing issue affecting Zope 2, though. I think you'll spend months doing this and get a cool reception at best, and at worst finding your work rejected out of conservatism. If I were in control of a budget, I wouldn't spend it on this. ;-) If you really want to do this (and prepare to spend months on it: once you start digging, you may find yourself in a hole), I suggest you do it in steps. 1) Change DTML into ZPT, but don't change anything else. At least this will give you a starting point and will make maintenance easier. 2) Do some real usability analysis and come up with a consistent design that's going to deliver some real benefits. You'll need to go through a relatively detailed process of getting community agreement on that. 3) Pilot this and get some feedback on a branch. 4) Presuming people agree with the direction, roll the new look and feel out across the ZMI. I also think there's a company out there that has a possibly-commercial ZMI replacement that's more AJAX-y and pretty. Maybe worth looking for that, though I forget the name. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Am 06.02.2010, 17:32 Uhr, schrieb Martin Aspeli <optilude+lists@gmail.com>:
If the reason is entirely aesthetic, please consider that there is a ton of documentation out there, including books in print, which refers to the existing UI that's been in place for years and years. Changing it purely for aesthetic reasons would probably do more harm than good, and confuse a lot of users.
It would be as much a 1:1 replacement of the existing ZMI using ZPT for templates and CSS for presentation. This could then be the basis for a usability-based sprucing up. My use of the term aesthetic is probably misleading. Just as it is important to update the Python code to work with the newer releases of Python I think the aesthetic components should be brought up-to-date technically. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
On Sat, Feb 6, 2010 at 17:16, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
1) Move to a more recent version of HTML (HTML 5 without the new tags), CSS 2.1 based layout and iFrames for containment and use ZPT instead of DTML
I would claim that's several steps by itself. ;)
2) Replace frames with aysnchronous communication
Why? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Am 07.02.2010, 17:57 Uhr, schrieb Lennart Regebro <regebro@gmail.com>:
I would claim that's several steps by itself.
You're right, of course: but they are related: 1. implement design in HTML 5; 2. Minimal styling in CSS 2.1; 3. Migrate DTML to ZPT
2) Replace frames with aysnchronous communication Why?
Oh, years ago I developed an allergy to frames of any kind and became convinced that they had no place in "proper" HTML. They've been kept around for convenience and the problems of rolling out a proper replacement for changing parts of a part of a page, although this shouldn't really ever have been a problem with Zope. But this is very much a side-show. For anyone who's interested I've spent quite a bit of time this weekend migrating some CMF based HTML to HTML 5 (the nicest thing about it is actually not having to worry about the version number) you really do end up with significantly more legible and compact HTML and more manageable CSS. I plan to pick up my work on updating the CMFDefault skin on the basis of this and then move to ZMI. If anyone wants to get together on this I am at PyCon and hope to have a couple of days at the Plone Dom(e) Sprint in March. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
Matthew Wilkes wrote:
On 2010-02-06, at 1257, Charlie Clark wrote:
Migrating from DTML to ZPT would add weight to the "dog food" argument and should be fairly straightforward. ZPT came on the scene shortly after I started playing with Zope and is one of the biggest reasons for me sticking with it. The ZMI is probably the last big dependent of DTML in Zope 2 so it would be nice to be able to remove that dependency for Zope 2.
It seems like a lot of work for no gain. I can think of a couple of examples where DTML templates are monkey-patched in Plone and none of those are anything particularly vital. DTML works for the ZMI, new pages can be written in ZPT, why bother going back and changing them all?
I mean, how often do you really need to do maintenance on the security form, for example?
Although new code won't have robustness as a 10 years old very well tested code, security is not the issue here. IMHO, it should be very important to reduce the stack to provide one-- and preferably only one --obvious way to do things. My concern are newcomers and technology adoption in general. My perception is the code was evolving among the years, finding new and better ways to do certain stuff, these were added into the core but most of the time the old way still remains. So, you usually have more than one way to do many things. At the same time, it's true there's a trade-off between effort, removing well-tested-code and value, but if there's not a pattern-deprecation or component-deprecation policy, when a newcomer has to learn the framework, He has to spend a valuable part of the time studding how things did work, how some people envision it should work and from these, He has to deduce how it really works. Probably, we're talking about documentation and not code, as Yusei Tahara suggest. On the other hand, I hope I'm writing this mail in a right way because it's not my intention to make critic nor complain. I'm just trying to share some perceptions (not facts) from a relatively newcomer who's curious how Zope is made and how He can contribute to make it better. Kind Regards r. -- http://robertoallende.com
On Thu, Feb 4, 2010 at 04:59, Roberto Allende <rover@menttes.com> wrote:
Probably at this point of the conversation is the right moment to ask if it would make sense to improve Zope2's ZMI, removing frames and perhaps DTML code and probably removing all the dtml from zope2.
I think it works just fine as it is. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Hi, On Wed, 03 Feb 2010 14:20:08 +0100 Tom Gross <itconsense@gmail.com> wrote:
Hi all,
with HTML5 the frame-elements will die. It will probably take some years before the browser-support of HTML4 will stop, but still. Are there any alternative implementations for the Zope2-ZMI?
There is a package zmi.core in the Zope-svn, but except some links to other packages there is nothing in it. Is the package alive and what's the targeted platform: Zope2, BlueBream, grok?
I have been working for zmi.core for several months and it is still under construction(sorry). The target was Zope3 and now it's BlueBream. Of course we can use it for grok. Zope2's ZMI is different. Regards, -- Yusei TAHARA <yusei@domen.cx>
participants (12)
-
Alex Clark -
Andreas Jung -
Charlie Clark -
Christian Theune -
Hanno Schlichting -
Lennart Regebro -
Martin Aspeli -
Matthew Wilkes -
Roberto Allende -
Tom Gross -
Tres Seaver -
Yusei TAHARA