Menu
▾
▴
phpwebsite-developers
|
From: George B. <gbr...@lu...> - 2004-08-06 00:00:00
|
For some reason, I didn't get Eloi's response to my original message (his response is copied below). Anyway, the more I think of it, the more I think what would be useful is a core section class that's designed to work like the item class. The item class has to be told what table to use in the database (so the module using it does the table creation on boost) and the item class goes looking for the calling class and its variables and checks how they line up with the columns in the table. There are probably other neatsy-keen techniques involved, but that allows one to use the item class to store just about anything as an item. A section class could do the same, and if the programmer were happy with the basic capability (to edit and view sections consisting only of text or image or both, and a subtitle), she could use it pretty much un--altered. Anyway, there is no core section class. I could write one, I suppose, based on PHPWS_Section. But maybe that's not the best way to proceed. I've been thinking of a newspaper module that offers a choice of several layouts, each with one or more sections, and lets users edit each section to add title, text or image or both as in article or Pagemaster. To create an edition, you choose a layout and then fill in the corresponding sections. It shouldn't be too hard to do, but I was trying to shortcut things by commandeering Pagemaster's section code. Which I can do, of course, by simply copying it and changing some parameters. Does that make it clearer, Eloi? George > It"d work, but you"d have to consider things like how to keep it from > creating a new page instead of a new newsletter and so forth. > > I"m not certain you"re attacking the basic question from the right > angle, though. > What are you looking for in this Student Newsletter Module? |
|
From: Shaun M. <sh...@ae...> - 2004-08-06 02:48:33
|
On 6 Aug 2004, at 00:59, George Brackett wrote: > > Anyway, the more I think of it, the more I think what would be useful > is a > core section class that's designed to work like the item class. The > item > class has to be told what table to use in the database (so the module > using > it does the table creation on boost) and the item class goes looking > for the > calling class and its variables and checks how they line up with the > columns > in the table. There are probably other neatsy-keen techniques > involved, but > that allows one to use the item class to store just about anything as > an > item. A section class could do the same, and if the programmer were > happy > with the basic capability (to edit and view sections consisting only > of text > or image or both, and a subtitle), she could use it pretty much > un--altered. > > I like that idea. You'd also need to be able to specify a template for the section ala Pagemaster/Article so that you could position images but I guess that's there already in Pagemaster. It'd actually be nice to standardise on this then you could have the same templates for all mods that use sections rather than having to edit the Article templates, the PageMaster templates and the Announce templates (yes I know it only has one just now, but this would add image placement easily if converted to use a section object). I do this on nearly every design I do as the standard templates are all different with some using bold titles, some using h3 and various different methods of positioning images from floats to tables with random padding. Does it also need a SectionManager for section ordering, page breaks and page templates or is that going too far and should be left to the module? Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Eloi G. <el...@re...> - 2004-08-08 20:45:08
|
I don't know why, but Sourceforge almost always delays my submissions to this list... I understand your goal a lot more now, but I think it can be achieved with existing modules. Article Manager (and PageMaster if it fully supports page templates now) is designed for just that purpose. A specific newsletter layout is defined as the overall page template design plus any particular combination of section templates. If you add in section templates that utilize "div"s with "float:left/right" to define columns, then you can end up with any layout you choose! Once a particular layout is designed, then all the designers have to know is that Layout#1 consists of Page Template "Layout_1" with sections in the order of "Right_Column_Top", any number of "Right_Column_Middle", "Right_Column_Bottom", "Headline", and any number of "Body". Or if you want to make it even easier, you could submit an RFE (or a patch ;)) to allow either module to clone an new article/page off of an existing blank one. On the other hand, if you wanted to make the newsletter module create the articles itself, the technique is illustrated in the importation scripts. Personally, I think our collective coding time would be better spent on quite a few other core class ideas than a universal section class. There are only a very few possible uses for the page/section paradigm, and I'm constantly looking for an easy-to-use, non-javascript-intensive way to get away from it and still retain the layout flexibility. -Eloi- |
|
From: Shaun M. <sh...@ae...> - 2004-08-10 02:43:23
|
On 8 Aug 2004, at 21:28, Eloi George wrote: > > Personally, I think our collective coding time would be better spent > on quite a few other core class ideas than a universal section class. > There are only a very few possible uses for the page/section paradigm, > and I'm constantly looking for an easy-to-use, > non-javascript-intensive way to get away from it and still retain the > layout flexibility. > Since the sections are mostly a way to manage and layout images alongside text rather than to divide text into sections, the problem is really to solve an easy way for newbies to insert and manage images without knowing html. Maybe that is actually best served by a wysiwyg tool like htmlarea/hypertextarea as it looks like Word rather than them having to work out templates and sections. The only real (ignoring weird things like PDAs and phones) problem area is Mac users on MacIE and Safari as there isn't a solution for them. Then again, that's a small bunch to annoy and they can always use Firefox instead. Safari v1.2.3 has just been released and I could have sworn Hyatt was saying it'd have contentEditable in that version. I'll have to find out although Apple take a while to actually release changelogs. MacIE is a dead product anyway. Personally, I end up ftping my images up and typing in the html myself and not using sections a lot of the time. Maybe there should be an 'advanced' interface which just simply had a method of uploading images and a simple 'click on the thumbnail' interface that inserted the html at the cursor. A Preview button is handy also that would preview the page in a separate window so you could see your layout whilst editing. Then you just need Page breaks and TOCs. In 0.8x I just added a bit of code that looked for [PAGE BREAK] in the content. Maybe something similar. Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Eloi G. <el...@re...> - 2004-08-10 14:43:41
|
> Since the sections are mostly a way to manage and layout images > alongside text rather than to divide text into sections, the problem > is really to solve an easy way for newbies to insert and manage images > without knowing html. Well, that and to allow easy layout of entire blocks of text without showing the underlying html, but your statement of the problem is correct. We have to find a way to shield the user from having to learn (or look at) any form of markup language. > Maybe that is actually best served by a wysiwyg tool like > htmlarea/hypertextarea as it looks like Word rather than them having > to work out templates and sections. I just looked at that again. I like it, but I'm still worried about non-jscript (or browser-) compatible users being exposed to all that underlying markup. Maybe I'm making too big a deal out of it -- I mean, what's the odds of a sight-disabled user having to edit an article created by someone who likes to "put lots of pretty colors" in the text? Hmm. I just realized that I'm going to have to start callling the module "phpwsArticle Manager." [groan] > MacIE is a dead product anyway. I've been saying that about Macs in general for years. People still keep buying the damn things. > Personally, I end up ftping my images up and typing in the html myself > and not using sections a lot of the time. Maybe there should be an > 'advanced' interface which just simply had a method of uploading > images and a simple 'click on the thumbnail' interface that inserted > the html at the cursor. Use of htmlArea would certainly allow that to happen. > Oh, and I forgot one of the points whilst I was typing. IME the > easiest method for newbies is to remove the editing of pages from the > browser completely and give them a client side app and an XML-RPC > blogger style editing interface. There's loads of really nice wysiwyg > tools for layout outside the web. Adding XML-RPC onto announce, > article and pagemaster for submitting pages would make a few of my > users more than happy. Yes, I remember looking at the ones you'd suggested some time ago. They didn't seem to support images without ftp'ing them up manually. Whatever solution is used has to be integrated in such a way that the module knows which pictures to delete/archive when it deletes/archives the article. Can you point me to one that does? Or at least reports where the pics were uploaded to? |
|
From: Spiggy T. <sp...@vi...> - 2004-08-10 14:54:39
|
>> MacIE is a dead product anyway. > > I've been saying that about Macs in general for years. People still > keep buying the damn things. Hehe. MacIE and a Mac is a slightly different thing :) > Use of htmlArea would certainly allow that to happen. > Yes, I remember looking at the ones you'd suggested some time ago. They > didn't seem to support images without ftp'ing them up manually. > Whatever solution is used has to be integrated in such a way that the > module knows which pictures to delete/archive when it deletes/archives > the article. Can you point me to one that does? Or at least reports > where the pics were uploaded to? > there is an image manager/uploader addon available. its a bit buggy though. we (here at work) are moving from devedit (commercial) to htmlarea and we have a working addon thingy done, with http upload. the htmlarea code is really nice to work with but you have to be up to par with highlevel object oriented javascript code. paivi -- Give a man a match, and he'll be warm for a minute, but set him on fire, and he'll be warm for the rest of his life. (Terry Pratchett) |
|
From: Shaun M. <sh...@ae...> - 2004-08-10 15:31:40
|
On 10 Aug 2004, at 15:44, Eloi George wrote: > > Well, that and to allow easy layout of entire blocks of text without > showing the underlying html, but your statement of the problem is > correct. We have to find a way to shield the user from having to > learn (or look at) any form of markup language. > I always thought blank lines between blocks of text was the best way of indicating they are a separate block of text. Some people call them paragraphs. Not sure it'll catch on though. ;-) >> Maybe that is actually best served by a wysiwyg tool like >> htmlarea/hypertextarea as it looks like Word rather than them having >> to work out templates and sections. > > > I just looked at that again. I like it, but I'm still worried about > non-jscript (or browser-) compatible users being exposed to all that > underlying markup. Maybe I'm making too big a deal out of it -- I > mean, what's the odds of a sight-disabled user having to edit an > article created by someone who likes to "put lots of pretty colors" in > the text? > It's a pity to have to make a section of users 'second class' by implementing a solution that works for the majority of users but the simple answer is a) switch javascript on b) Use Firefox Then you're down to just the special cases of providing access for the disabled and I can't imagine that a wysiwyg tool is any worse than the textarea/buttons we have now. > >> MacIE is a dead product anyway. > > I've been saying that about Macs in general for years. People still > keep buying the damn things. Yep. More this year than they did last year. Then again, there's more people buying Windows than they did last year also. :-( >> Oh, and I forgot one of the points whilst I was typing. IME the >> easiest method for newbies is to remove the editing of pages from the >> browser completely and give them a client side app and an XML-RPC >> blogger style editing interface. There's loads of really nice wysiwyg >> tools for layout outside the web. Adding XML-RPC onto announce, >> article and pagemaster for submitting pages would make a few of my >> users more than happy. > > > Yes, I remember looking at the ones you'd suggested some time ago. > They didn't seem to support images without ftp'ing them up manually. > Whatever solution is used has to be integrated in such a way that the > module knows which pictures to delete/archive when it deletes/archives > the article. Can you point me to one that does? Or at least reports > where the pics were uploaded to? > KungLog. It's ace. Oh, you need a Mac. ;-) AFAIK the blogger/metaweblog or whatever apis don't support picture uploads so all the offline tools do it by ftp. Maybe the newer Atom API does with newer blog software. Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Eloi G. <el...@re...> - 2004-08-10 18:42:39
|
> I always thought blank lines between blocks of text was the best way > of indicating they are a separate block of text. Some people call them > paragraphs. Not sure it'll catch on though. ;-) Wow. There's an actual *name* for them?!?! Note: For those who aren't sure if we're joking or not, I was more referring to those instances where you wanted your users to be able to make a sidebar that sticks to the right side with a company logo background/watermark and an image rollover as the title. All they'd have to do is select that template and enter the text. > It's a pity to have to make a section of users 'second class' by > implementing a solution that works for the majority of users but the > simple answer is > > a) switch javascript on > b) Use Firefox Naw, we're still back at square one because a lot of corporations prohibit the use of javascript on the company-mandated browser (usually IE). My sitelogs show that most browsing is being done between 9-4 on Mondays through Fridays on the bosses' high-bandwidth line. It's weird. You can actually set your watch by looking at where users are logging in from. > Then you're down to just the special cases of providing access for the > disabled and I can't imagine that a wysiwyg tool is any worse than the > textarea/buttons we have now. I think it would be worse in the sense that the exsistence of a wysiwyg tool encourages people to use more markup, making a text version more unreadable. Take a look at http://www.interactivetools.com/products/htmlarea/index.html#demo using FireFox. Takes you a while to understand where to edit what. A blind editor would be dealing with that all day long. |
|
From: Shaun M. <sh...@ae...> - 2004-08-10 02:59:30
|
On 8 Aug 2004, at 21:28, Eloi George wrote: > > Personally, I think our collective coding time would be better spent > on quite a few other core class ideas than a universal section class. > There are only a very few possible uses for the page/section paradigm, > and I'm constantly looking for an easy-to-use, > non-javascript-intensive way to get away from it and still retain the > layout flexibility. > Oh, and I forgot one of the points whilst I was typing. IME the easiest method for newbies is to remove the editing of pages from the browser completely and give them a client side app and an XML-RPC blogger style editing interface. There's loads of really nice wysiwyg tools for layout outside the web. Adding XML-RPC onto announce, article and pagemaster for submitting pages would make a few of my users more than happy. Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Matthew M. <ma...@tu...> - 2004-08-10 12:33:42
|
> Maybe that is actually best served by a wysiwyg tool like > htmlarea/hypertextarea as it looks like Word rather than them having to > work out templates and sections. We are trying to implement htmlarea within 0.9.4. It needs more testing but it appears to work well. Matthew McNaney Internet Systems Architect Electronic Student Services Appalachian State University Phone: 828-262-6493 http://phpwebsite.appstate.edu http://ess.appstate.edu |
|
From: Mike N. <mh...@us...> - 2004-08-10 18:27:38
|
On Tue, 2004-08-10 at 05:20, Matthew McNaney wrote:
> > Maybe that is actually best served by a wysiwyg tool like
> > htmlarea/hypertextarea as it looks like Word rather than them having to
> > work out templates and sections.
>
> We are trying to implement htmlarea within 0.9.4. It needs more testing
> but it appears to work well.
Matt,
It's unfortunate you weren't able to get Kupu to integrate smoothly. I
like the approach the kupu team is taking.
http://kupu.oscom.org/
--
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs
|
|
From: Shaun M. <sh...@ae...> - 2004-08-10 16:41:59
|
On 10 Aug 2004, at 15:44, Eloi George wrote: > > Yes, I remember looking at the ones you'd suggested some time ago. > They didn't seem to support images without ftp'ing them up manually. > Whatever solution is used has to be integrated in such a way that the > module knows which pictures to delete/archive when it deletes/archives > the article. Can you point me to one that does? Or at least reports > where the pics were uploaded to? > Done some more digging. Kung-Log has become ecto and now also runs on Windows as well. See http://ecto.kung-foo.tv/ The metaWebLog API supports image upload via this API http://www.xmlrpc.com/discuss/msgReader$2393 Full API at http://www.xmlrpc.com/metaWeblogApi By all accounts it's quite horrible but Dave Winer's API's generally aren't regarded too highly. He's also responsible for RSS 2.0. It does however work and is supported by a large number of tools. The Atom API seems to be where everyone is heading and that apparently will support image uploads embeded in the content but for the life of me I can't make head nor tail of their docs. http://www.atomenabled.org/ There are however a couple of good articles on xml.com. http://www.xml.com/pub/a/2003/10/15/dive.html - a nice overview of pervious apis used and why Atom is the dogs danglies. http://www.xml.com/pub/a/2004/04/14/atomwiki.html - Atom added to a wiki. It's obviously still not without problems. Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Mike N. <mh...@us...> - 2004-08-10 18:33:20
|
On Tue, 2004-08-10 at 09:41, Shaun Murray wrote: > The Atom API seems to be where everyone is heading and that apparently > will support image uploads embeded in the content but for the life of > me I can't make head nor tail of their docs. > http://www.atomenabled.org/ Shaun, Yes, and an Atom IETF working group was just approved. http://www.ietf.org/html.charters/atompub-charter.html -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs |
|
From: Wendall C. <wen...@83...> - 2004-08-12 18:54:49
|
Since Atom was approved, I'll be adding it to rssfeeds. However, I have some planning to do for how to better implement phpwsRSSFeeds into phpWS. Currently, I am just pulling data from mods that it works with directly from the database and formatting into an RSS 1.0 Dublin Core format. This isn't really proper, but working for now. I'd like to get everybody's feedback on the best format that would allow mods to register with rssfeeds, including, the options allowed, such as creating an Atom or RSS 1.0 feed for sharing module data, etc. I have some ideas, but would like to work on something that everyone could agree on. I have no plans of supporting RSS 2.0 other than display purposes. There is an excellent api provided via PEAR for all xml schemas related to RSS, including Atom, and I plan to continue to use PEAR whenever possible. I've opened a good line of communication with the devs that work on the libs we are currently using, so features can easily be added to the libs as needed. Wendall On Tue, 2004-08-10 at 11:39, Mike Noyes wrote: > On Tue, 2004-08-10 at 09:41, Shaun Murray wrote: > > The Atom API seems to be where everyone is heading and that apparently > > will support image uploads embeded in the content but for the life of > > me I can't make head nor tail of their docs. > > http://www.atomenabled.org/ > > Shaun, > Yes, and an Atom IETF working group was just approved. > > http://www.ietf.org/html.charters/atompub-charter.html -- "Only the ideas that we really live have any value." --Hermann Hesse (Demian) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X