vworld
Lobos, these lists have always been public nothing new here.
With respect to my comments in the email you pointed to I remember there were times when Xanthia was constantly being bashed on these forums by you and Shawn. My point in the email was we need to have a "fair and balanced" approach to the issue. This isn't about one or the other.....it is about giving people choices.
We've always stated your contributions to PostNuke have been appreciated. I've stated publically that Shawns contributions are appreciated not only by myself but as many know by thousands of users.
Enough said on the subject, happy googling!
Lets not do that... I respect the decisions of the moderator to delete any thread they consider an attack as on individuals in this forum... Attacking other members only results in a loss of respect for the individual doing the attacking.
As far as whats said here, I dont see the big deal... The discussion that these talk about is
1) the future of Xanthia,
2) the current state of Xanthia...
I have wanted to talk about these issues, because I am starting to document this area. I am in direct conversations with phpNut, and a few members of the team...
I have found 2 things..
First, unless the author of Autothemes wants to release the code under the GNU/GPL, the future of postNuke is infact Xanthia. I can see this...
The issues presented with Xanthia are currently a lack of a common and intuitive user interface and language, and the current abundance of bugs in the .750 version. Both of which can be solved... but how do we do this?
I feel the direction of Xanthia is to loose the style elements (Theme Colors, and Theme Settings)... This was a good idea, but the problem is that Themes contain colors that are combined with overlapping images. The Theme Settings could be cool for some applications, such as theme developers who sell/distribute their themes. The replacement of Theme Colors should be the ability to define a range of CSS's to choose from. That way, theme designers can provide a choice in colors by providing multiple CSS's to each theme.
IThe problem with the language of Xanthia is that:
A) Xanthia is a project codename, and shouldnt be the end name for the module... It took me a LONG time to make the connection of Xanthia to its meaning... I think renaiming this module is a good idea...
Lastly a decision of Xanthia storing templates on the file system or in the database has to be made. Either way, the templates still need to be reloaded anytime a change is made (due to the Cache). From an interface standpoint, it would be better if the theme was controlled in the database. Their then has to be a better way to export and import themes into the system...
What ever way this is done, it needs to be a all or nothing effort..
For example, if its going to be stored in a database, then the themes should be shared via a web interface. There should be a "import" function and a "Export" function... Both should interface with Zip or GZip, and would include uploads and downloads. The entire package would contain all information for the theme... The downside of this would be the inability to edit themes with macromedia directly on the server with Dreamweaver or an IDE. Images and HTML files could be uploaded and downloaded from the web interface and would have to be copy and pasted into the appropriate design interface. The upside to this would be the ability for "novice" users to import themes with little knowledge of filesystems, HTML, permissions or ftp.
If its going to be stored in the file system, then the themes should be shared via the current directory ftp method... The downside would be that it will remain harder for the "simple" user to add new themes. The upside is that the current "advanced" user would be able to take dreamweaver, Zend, or other IDE and input the file directly.
Either way the theme would have to be "refreshed" for Smarty caching to take off.
It is probably possible to come up with a compromised system that would provide both functionalities.
