Hi,
Oh, I see, I guess you were talking about editing template pages this whole
time... well, in that case, it's definitely not a Semantic Forms issue. That
also seems a little pointless: templates are code-intensive pages, that it
doesn't make sense to me to try to edit with a WYSIWYG editor.
-Yaron
On Wed, Sep 10, 2008 at 1:22 PM, CW <[EMAIL PROTECTED]> wrote:
>
> Are you using FCK to look at other pages in your Templates
> NS? ...doesn't it cause the same problem? If not, there must be a
> reason for it. It wasn't obvious for me at first; had to go looking
> for trouble...
>
> CW
>
> On Sep 10, 8:54 am, "Yaron Koren" <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > That's too bad. As you could guess, I have almost no knowledge of how
> > FCKeditor works internally, let alone the ability to fix it... I'm
> > guessing that the only time I'd get involved in trying to fix things
> > is if FCK works differently in the form from how it works in the
> > 'edit' page.
> >
> > -Yaron
> >
> >
> >
> > On Wed, Sep 10, 2008 at 6:43 AM, CW <[EMAIL PROTECTED]> wrote:
> >
> > > Yaron,
> > > This is promising. I have a question about using FCKeditor, though,
> > > because just yesterday I gave it a failing grade on our development
> > > server where we test all extensions before applying them to our
> > > production site. I found that it strips out some HTML tags when using
> > > IE7 (I have a bug in, but that crowd doesn't seem to be as responsive
> > > as the SMW/SF crowd--holding out little hope). Anyway, this problem
> > > is evident primarily in templates with <pre> tags that show how to
> > > call up a template on the template page view. ...I noticed it also
> > > with comments in complex templates, for example I've copied the
> > > Extension pages for all of the extensions we're running on our site
> > > and I've moved them to the Help namespace and associated them with the
> > > Advanced Editing or Administrators areas. ...and as you are probably
> > > aware, there are a lot of <!---Comment---> tags inside the Infobox
> > > Extension template. ...anyway, FCK was stripping them out, along with
> > > everything inside them, so I was losing half my templates.
> >
> > > Realize this isn't the FCKeditor list....but if you know of a way to
> > > fix this, maybe we could deploy it on Monday's release of our upgraded
> > > wiki...
> >
> > > CW
> >
> > > On Sep 9, 3:16 pm, "Yaron Koren" <[EMAIL PROTECTED]> wrote:
> > >> Hi everyone,
> >
> > >> Version 1.3 of Semantic Forms has been released. This is a major
> > >> version release, with three new files, plus a lot of other additions
> > >> and changes:
> >
> > >> - support was added (finally!) for WYSIWYG editing, using the
> > >> FCKeditor MediaWiki extension. Currently it works only for the "free
> > >> text" input, though eventually I hope that it will be able to edit
> > >> other textarea inputs in the form. To get this working, you only need
> > >> to install the FCKeditor extension on the wiki. If it shows up
> > >> correctly in regular 'edit' pages, then it should also show up
> > >> automatically in forms. Thanks a lot to Eugene Mednikov for this
> > >> exciting new feature.
> >
> > >> - tied in with this new feature, I did some refactoring of the code,
> > >> moving a lot of the Javascript and utility functions defined in
> > >> /includes/SF_FormPrinter.inc into a new file,
> > >> /includes/SF_FormUtils.inc. This should hopefully make the code
> > >> somewhat more readable and manageable.
> >
> > >> - in a change that I probably should have done a while ago, the
> > >> parsing of template calls has (I believe) been fixed, so that pages
> > >> that contain templates calls within template calls, or variables like
> > >> "{{PAGENAME}}" within template calls, are now handled correctly by
> > >> forms. I should note that I have some mixed feelings about this bug
> > >> fix: I don't personally think that inner templates and variables
> > >> should be used, because it means that users will see curly braces
> > >> within forms, which I think adds a lot of unnecessary confusion. But
> > >> in any case, it works now.
> >
> > >> - new implementations for the #arraymap and #arraymaptemplate parser
> > >> functions were added that handle embedded templates, variables and
> > >> parser functions better, that work for versions of MediaWiki I believe
> > >> 1.12 or higher; thanks very much to Daniel Friesen.
> >
> > >> - on pages that redirect the user, a "loading" image, which is one of
> > >> those rotating circles, now appears on the page. This happens in two
> > >> places: when the user enters a page name in the form input and is
> > >> redirected to either 'AddData' or 'EditData', and when the user hits
> > >> Save/Preview/etc. in a form and is redirected to the page itself, with
> > >> its new content. The idea is that this image (a) let the user know
> > >> what's going on, especially if the redirect takes a while, and (b)
> > >> hopefully clarifies to users why they need to hit the "back" button
> > >> twice to get back to the form. Thanks again to Eugene Mednikov for the
> > >> idea and most of the code. We both agreed that this feature might get
> > >> annoying, but that it's worth trying out to see what people think. So,
> > >> let me know what you think. :)
> >
> > >> - per good MediaWiki practice, the ability to edit "restricted" form
> > >> fields is no longer determined by who is allowed to delete pages, but
> > >> rather set by a new permission type, 'editrestrictedfields'. By
> > >> default this permission is assigned only to sysops in SF_Settings.php.
> >
> > >> - the 'AddPage' special page can now be used to redirect directly to
> > >> forms - if one goes to a URL that looks like
> > >> /Special:AddPage/form-name/page-name, it will redirect to either
> > >> /Special:AddData/form-name/page-name or
> > >> /Special:EditData/form-name/page-name, depending on whether or not the
> > >> page exists. This is useful for linking to the editing of a page from
> > >> outside the wiki.
> >
> > >> - the "listbox" form input type now takes a "size=" parameter.
> >
> > >> - the 'namespace=' parameter in the query string now works for forms
> > >> that set an automatic page name - due to a bug, this wasn't working
> > >> before.
> >
> > >> - I fixed a bug I added in the last version, 1.2.10, that added some
> > >> whitespace to the top of very form.
> >
> > >> - another new file was added, '/includes/SF_FormEditPage.php', that
> > >> holds a class that may eventually be used to let the form remain
> > >> displayed when the user hits "Show preview" or "Show changes".
> > >> Currently it's not yet in use, possibly pending some more changes to
> > >> core MediaWiki code, but hopefully it will be usable by the time
> > >> MediaWiki 1.14 is released. Thanks again to Daniel Friesen for his
> > >> dedicated work on this feature.
> >
> > >> - MediaWiki has a new feature that lets you create aliases for special
> > >> pages, so that a certain special page can be reached at more than one
> > >> name. SF now has support for this feature, in a new file called
> > >> /languages/SF_Aliases.php - thanks to internationalization guru
> > >> Siebrand Mazeland for this addition.
> >
> > >> - language support was added for Erzya and Gothic.
> >
> > >> By the way, if you're wondering, I'm not trying to sync up SF's
> > >> version numbers with those of Semantic MediaWiki, although it
> > >> certainly looks that way... SF's release schedule so far has been
> > >> faster than SMW's, so they'll probably be out of sync again before
> > >> long.
> >
> > >> -Yaron- Hide quoted text -
> >
> > - Show quoted text -
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Semantic Forms" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/semantic-forms?hl=en
-~----------~----~----~----~------~----~------~--~---
