November 2005 - Development - lists.drupal.org

Re: [development] replace drupal.js with prototype.js?
by Konstantin Käfer 16 Nov '05

16 Nov '05

In fact, prototype are separate files. They are just put together for the release. See http://dev.conio.net/repos/prototype/src/ for the single files. 2005/11/16, Richard Archer <drupal.org(a)juggernaut.com.au>: > At 11:34 AM +1100 16/11/05, Jeremy Epstein wrote: > > >Prototype does indeed seem to be a very light, clean, and extensible > >library: but nonetheless, it is nowhere near as light as drupal.js. > >Quick comparison: > > > >Drupal.js: 281 lines, 6.21KB > >Prototype.js: 1039 lines, 27.29KB > > All the Drupal .js files combines come to 18 kB. > > Is it possible to strip prototype down a bit? > > There are a lot of comments in the file that wouldn't be needed > in a live site. > > What about separating it into function-related files and just > sending the bits the page needs? > > ...R. > -- http://timcn.de

1 0

RE: [development] subversion
by Nelson, Curtis 16 Nov '05

16 Nov '05

> What do you think of bzr (aka bazaar-ng)? I say, get prepared now, and launch in sync with bzr 2.0. Uh oh. This could be the start of a very long thread. One idea might be to take a look at using Tailor (http://www.darcs.net/DarcsWiki/Tailor) to try out or offer different repositories -- its seems to work well for syncing between cvs and subversion and I've seen projects that just off-load from CVS to mercurial for development. In any case you can use it to see what the code-base might look like in a different system. -Curtis

1 0

[drupal-devel] new CVS accounts
by Dries Buytaert 16 Nov '05

16 Nov '05

Hello world, we approved a number of new CVS accounts. Please welcome our new contributors, and assist them as necessary. -- Dries Buytaert :: http://www.buytaert.net/

8 11

Re: [CS dev] Help with a CivicSpace Theme Layout... (Read it, you know you want to! :)
by Trae McCombs 16 Nov '05

16 Nov '05

On Sat, 2005-11-12 at 10:10 -0500, Liza Sabater wrote: > Hey Trae, > > I'm being a bit lazy here but ... for Mac people, can you post a > screenshot of what it looks like on IE? I am assuming you mean MS/IE > not Mac/IE, which is not being supported AT ALL by Microsoft. Right, well, I am not supporting IE for Mac, as you said, neither is Microsoft. There are other better and free browsers for OSX [ Firefox / Safari ] > Which brings me to one request : CivicSpaceLabs (that means you ;) > ought to offer the option right off the bat to include in the theme a > browser sniffer so that people with older browsers can default to a > 'downgraded' version of the theme. I cannot stress how important it > is for us to move people to Firefox and this should be the way to do > so. Please remember that a lot of NGOs don't get new equipment. > Usually grassroots NGOs and educational NGOs get donated equipment > with outdated software. Let's just educate people to the best options > they can have by pointing to the obvious: If you want a better > browsing experience, go Firefox. Pardon my ignorance, NGO? I do understand about donated computers and low end systems as I've worked with groups in the past on issues dealing with Digital Divide problems. The thing is, the more we backwardly rig our websites to work with old, outdated, buggy, insecure browsers, the more problems the web will continue to have. My personal feelings are: Firefox is free, download and install it. Or grab another free browser, or if you want to use Microsoft products, upgrade to IE6. I think we, web developers, spend too much time trying to fix a website so it works on Some browser from 1994. I say make sure your CSS and HTML is validated, and work from there. > Also, and I almost forgot about it, where is Longhorn? There is a > looming development and design disaster for a lot of NGOs if Longhorn > proves to be as much as a pain in the ass as it's predecessor --no > matter how standards compliant they're claiming to be. Don't even get me started on IE7. :) > This is a huge issue that ought to be address through the development > of these themes. It's really not just about how pretty the site is > going to look off the box. CivicSpaceLabs should consider addressing > the pressing need of saving the already strained resources and man- > hours of NGOs and grassroots organizations lost to theme debugging; > especially once MicroSoft unleashes it's new OS and browser from hell. I would actually be all for some sort of browser detection thing if it worked 100% where it educated people to grab a standards compliant browser. But then again, we'd be also telling IE people to get a clue, and most people aren't for that. *sigh* Again, I'd love to have you hang out with us on #cstheme on irc.freenode.net where we can discuss this and other issues to help make the CStheme better. Thanks, Trae > / liza > > > > On Nov 11 2005, at 09:45 PM, Trae McCombs wrote: > > > Ok, so let me post a wee bit of information. Please check this URL > > out first: > > > > http://civicspacelabs.org/home/CivicSpaceTheme > > > > This will, or should, bring you up to date on some of the terms I'm > > going to be using below. The CivicSpace Theme (CST) is using some > > new concepts in themeing. > > > > Anyway, my question currently is this. > > > > The Federation Layout looks fine on Firefox, but for some reason it > > isn't working in IE. Meaning, it doesn't match it's thumbnail. If > > you simply compare both browsers, and notice how FF looks and IE > > doesn't then you should see what's wrong. I can't figure out what > > is causing it. Someone suggested #content, however that only > > changes the internal body. > > > > Here is the site where I am currently working on things, and the > > Federation Layout is selected at present: > > > > http://demo.civicspacelabs.org/home/ > > > > Also, this may be of some use. It is the Plan of action, or guide > > we are trying to use for the CST: > > > > http://civicspacelabs.org/home/CivicSpaceThemePlan > > > > Please, feel free to join me on #cstheme on irc.freenode.net and > > discuss any of these issues. I do look forward to your help. > > > > Thanks, > > Trae > > > > PS. Kieran (Amazon) says I can blame him for this [and any and all > > further silly questions I have -- oh wait, maybe he didn't say all > > of that exactly. :)] > > > > -- > > Trae "occy" McCombs || http://occy.net/ > > Founder - Themes.org // Linux.com > > CivicSpaceLabs - http://civicspacelabs.org/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: civicspace-dev-unsubscribe(a)civicspacelabs.org > > For additional commands, e-mail: civicspace-dev- > > help(a)civicspacelabs.org > > > > -- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/

7 13

Give a guy some love! (or at least some attention)
by Steve Dondley 15 Nov '05

15 Nov '05

Even if you think the patch at http://drupal.org/node/37283 sucks, I want to know!

4 3

Files on previews
by Ber Kessels 15 Nov '05

15 Nov '05

Hello all files people. I am getting somewhere with my files stuff, but i'd like some gurus and/or original file.inc developers to comment on an issue: We have a lot of code in upload.module and some in file.inc to cater previews. In case of a preview, we try to serve the files from the temp folder, or we try to generate temporary URLS etc (since we have no nid yet!) This is a bit crufty IMHO. I want to change this, in my code to behave as follows: * A node (or comment or whatever) that has attachements that are valid are inserted into the files system all the way. we only leave the obid (the column in tghe files dir for object ids like nid) empty * invalid files are deleted immediately * Once the object is inserted and saved, we have an obid (nid, mostly) and we update the table. That way, on loads of previews, we should be able to just use the urls, apis and functions we use normally. So: Why did we choose for the current method of writing all the exceptions for previews? Did I miss something important that renders my idea impossible? Should I take care of something else? Ber --

6 8

Drupal Enhancement Proposals (DEPs)
by Adrian Rossouw 15 Nov '05

15 Nov '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I need to preface this by saying that I don't think our current community processes are 'broken' per se, since they have obviously brought us this far, however I have noticed some areas in which there could be improvement and I would like to make some suggestions towards getting a smoother development cycle for all of us. My primary interest with this proposal is to foster co-operation, and allow us to better manage the project in the future. I feel that one of the primary problems we have is that there is not enough co-operation between different developers, and I feel that this problem stems from lack of communication. Up to this point, communication has been strictly informal. This has the benefit of not tying up people doing ground work, and is essentially an extension of our 'talk is silver, code is gold' mantra. And this is great. Good working code is our primary goal, and it has suited our goals up to this point perfectly. The problem with this however is, that it does not scale. With one, or even two people on the project it might work, but the moment you get more than that involved, communication becomes a lot more work than it should be. The other problem is that communication on projects like these tend to be on a personal level, and the only way to get more developers involved in the project is either through direct requests, or constant badgering on the forums/irc. Even if you do get someone else interested, getting that person up to date on the goals and status of the project , and to become a contributing member is still a lot of work. Also, the only way for an external developer to become involved in such an on-going project is to search the forums, find people who might even be remotely interested in the same thing, go talk to people on irc, see if anything is being done in whichever direction they intend to work in. It's a lot of work, and most developers don't bother. They end up re-inventing the wheel, because it's really hard for them to get accurate information about what's going on in the Drupal community. What I would like to suggest, is that we introduce a proposal system, whereby we create an official proposal document for any large changes we undertake as a community. This process would be modelled on the jabber.org JEP process, which in turn is modelled on the IETF process. What we would essentially do is create a document, that has an official number, a status and an owner. This document would be modelled on JEPs (http://www.jabber.org/jeps/jep-0143.html) and would explain the basic goals of the project, reasoning behind it, requirements, security considerations and so forth. How I imagine the basic workflow would be, is that someone writes a proposal, in the correct format, that gets published as a draft. At a certain point the draft then gets sent to drupal-devel, and developer comments are factored in. Then it gets published on Drupal.org, and user comments get factored in. At this point, we have a proposed DEP, and anyone who has any interest in working towards that knows what has been decided to be the best approach, who is working on it, and what is the status of it. Another thing that led me to this conclusion, was the recent discussion about the formation of the 'theme team', which I felt was not actually aligned with our goals. We already have a theme forum, which doesn't see much action, since I think the informal communication has proven to not be adequate. What the proposal structure would do, is allow us to create SIG's (special interest groups), whose purpose would be to foster discussion, and create proposals with a certain goal in mind (ie: theme sig, usability sig, localisation sig, etc.) Benefits : For Developers : Lessens duplicated efforts. Has a summary of the current status of things. Allows us to collaboratively map out what we are working towards. It's an actual spec, and although there is such a thing as feature creep, at least we know when it's 'done' For Documentation : Provides reference information for the design and implementation of features. For End Users : A more transparent view of where we are heading, what changes we are making and why. More eyes, which might bring up more issues, helping the design along. Get them more involved with the project, without having to wade through the forums. For Investors : Allows investors to see projects within the community and financially support the right people towards meeting their goals. Creates a common process to interface commercial and community developers with each other. Reverse bounties. For Dries : Allows for more accurate roadmaps. (ie: DEPs 0341 and 0342 are destined to be in the next release) Knowing the status of things. For all of us : Gives us a better map of people's interests. More visibility to what you are busy doing, and it might make you some money. One thing I should say, is that I am not trying to stop us from developing the way we are now, it's not broken, i'm not trying to fix it. What I am saying is that we could make this more formal path available, to allow us to collaborate more effectively on things. I am also not trying to bog down what we do. Implementing for now could simply be a book page that we maintain as we are involved in the project. I have some ideas in the future to expand the integration in a meaningful way, but that's probably a topic for a DEP of it's own. Just because we are documenting what we are doing, doesn't mean we can't write code while we're doing it. We're obviously going to have times when we have a couple of different implimentations of the same thing competing with each other, provided they are different enough approaches... but that's healthy. I am also not saying that we will get this right the first time, but what I propose is that we set up such a process and then create a DEP 0001 which is the dep handling the community process, and after every release we review it again and make revisions based on what worked and what didn't. I really feel that if we decide on a method we need to stick with it for a while though. So these are some of my thoughts, and I would love to have the community's opinion on the idea. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDdkV3gegMqdGlkasRAr+aAKCoGKZ8hnqtqDm658DJBX5USTQ0fgCeI1tw rY2I2L6dSV6MBGuO767Jazk= =Z4mD -----END PGP SIGNATURE-----

19 37

Drupal-related podcasts
by Dries Buytaert 15 Nov '05

15 Nov '05

http://www.echochamberproject.com/node/690 http://www.echochamberproject.com/node/691 -- Dries Buytaert :: http://www.buytaert.net/

1 0

Introduction
by Richard Archer 15 Nov '05

15 Nov '05

Greetings, I've been hanging around for a couple of months now, but I recently had a CVS account approved so a more formal introduction is called for, I believe. My background is in network and unix system management. I have some rusty skills in SunOS, Solaris, AIX and Cisco IOS and current Linux skills. I have also done quite a bit of programming over the years in all sorts of languages, but mostly in MC68000 assembly, C, Perl, PHP and I guess shell script qualifies too. I can find my way around most programming languages and operating systems. I'm self-employed, running a one-man show, although I contract work out occasionally when I get very busy. The core of my business has been building and hosting static sites with the occasional shopping cart system or basic CMS interface. This side of the business is slowly drying up though, as everyone wants to be able to build and update their own sites through a proper CMS. So I intend to begin offering a CMS-based hosting package within the next year. This is (funnily enough) going to be Drupal-based. When working on Drupal my focus will be on core features that I need in order to meet the requirements of my customers or to make my life as service provider easier. Things like primary links, which almost every site has to have, enhancements to the menu system, better themability and ease-of-use of the admin interface. I will also be helping Matteo with maintaining the Inline module. Support for images is sadly lacking in Drupal, and I think Inline forms a very nice, simple foundation for allowing images to be easily placed into pages. ...Richard.

2 1

Re: [development] Drupal Enhancement Proposals (DEPs)
by Richard Archer 15 Nov '05

15 Nov '05

At 8:06 PM -0500 14/11/05, James Walker wrote: >applications... i'm also passively curious - of our 300+ cvs >contributors how many stay active? There has been 119 unique people commit to CVS since I subscribed to the cvs list on 22 September. ...R.

1 0