publex-developers Mailing List for PubleX Documentum Environment
Status: Alpha
Brought to you by:
cyqotiq
Menu
▾
▴
publex-developers — PubleX Developer Mailing List
You can subscribe to this list here.
| 2007 |
Jan
(21) |
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-02-26 15:53:39
|
Sorry guys, just wanted to let everyone know that I haven't given up on the project. We've been covered up at work lately, so I've been working 14-18 hours each day for the last two weeks. This should stop in the next few weeks, and then I'll be able to get back into the project. Until then, I'm confident that everyone is capable of working out details on their own. Again, I'm sorry I haven't been available lately, but I will be back into it again soon. Jason |
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-02-06 13:31:01
|
Ok,
I'll fix it as soon as I get home.
Jonas
Quoting PubleX Developer's Mailing List
<pub...@li...>:
> I'm not sure what happened. I can't use SVN while I'm at work, so I can't
> fix it from here, but feel free to do so yourself. The problem is in the
> file PubleX.UI.EditorWindowDesigner.cs at line 371. The following code
> should be inserted there (I'm not sure why it's missing):
>
> this.mnuMain.Items.AddRange( new
> System.Windows.Forms.ToolStripItem[] {
> this.mnuFile,
> this.mnuEdit,
> this.mnuFind,
> this.mnuView,
> this.mnuInsert,
> this.mnuTable,
> this.mnuTools,
> this.mnuStyles,
> this.mnuWindow,
> this.mnuHelp
> });
>
> Jason
>
>
> On 2/5/07, PubleX Developer's Mailing List <
> pub...@li...> wrote:
>>
>> Hi,
>>
>> Whenever I build and run PubleX, I can't see the menu. VS also
>> sometimes complains about a missing math_abs.png (or something like
>> that) file in some resource file. The "resgen" custom build actions
>> are failing, too. It might be some files missing (like the
>> math_abs.png file).
>>
>> Jonas
>>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job
>> easier.
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Publex-developers mailing list
>> Pub...@li...
>> https://lists.sourceforge.net/lists/listinfo/publex-developers
>>
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
|
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-02-06 12:35:15
|
I'm not sure what happened. I can't use SVN while I'm at work, so I can't
fix it from here, but feel free to do so yourself. The problem is in the
file PubleX.UI.EditorWindowDesigner.cs at line 371. The following code
should be inserted there (I'm not sure why it's missing):
this.mnuMain.Items.AddRange( new
System.Windows.Forms.ToolStripItem[] {
this.mnuFile,
this.mnuEdit,
this.mnuFind,
this.mnuView,
this.mnuInsert,
this.mnuTable,
this.mnuTools,
this.mnuStyles,
this.mnuWindow,
this.mnuHelp
});
Jason
On 2/5/07, PubleX Developer's Mailing List <
pub...@li...> wrote:
>
> Hi,
>
> Whenever I build and run PubleX, I can't see the menu. VS also
> sometimes complains about a missing math_abs.png (or something like
> that) file in some resource file. The "resgen" custom build actions
> are failing, too. It might be some files missing (like the
> math_abs.png file).
>
> Jonas
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Publex-developers mailing list
> Pub...@li...
> https://lists.sourceforge.net/lists/listinfo/publex-developers
>
|
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-02-05 19:08:05
|
Hi, Whenever I build and run PubleX, I can't see the menu. VS also sometimes complains about a missing math_abs.png (or something like that) file in some resource file. The "resgen" custom build actions are failing, too. It might be some files missing (like the math_abs.png file). Jonas |
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-02-02 22:19:16
|
The tables look pretty accurate. That should work for our needs. We will need a few additional fields in the Document and Users tables, but I'm sure you took that into consideration. In regards to the class responsible for creating a project, this will need to reside in PubleX.Core so that the server component may access it. The server component will actually be responsible for physically creating the documents and database entries. What the user does will only be an interface implemented in PDE. Otherwise, you are correct. These classes do need to be implemented. The PubleX.PDE.Document class is actually one of the first classes written in the project. It was originally going to be used for an individual XML file to keep track of all associated files (graphics, style sheets, etc). Most of this will still need to be implemented in the Document class, but this class may also need a way to communicate with the SQL server class to send the appropriate requests (checking-out/checking-in/link updates/etc). Jason On 2/2/07, PubleX Developer's Mailing List < pub...@li...> wrote: > > Hi, > > I've been busy for the last few days (end of semester, exams, etc..). > But now I'm back :) and I have a question about DB part of publex. > > > The database of every project will contain at least 3 tables: > > 1) TbProject > - PName > - PUsers (form TbUsers) > - PDocuments (from TbDocument) > - other fields (start date, end date, chapters, ..) > > 2) TbUsers > - UName > - ULevel > - UProject (from TbProject) > > ULevel: > - PM > - ProjectEditor > - PublicationControl > > 3) TbDocument > - DName > - DProject (from TbProject) > - DChapter > ... - document contents.. > > It's obvious that we need some classes describing our project structure. > There is one class: PubleX.PDE.Document but it does not have all the > fields needed by db. When Publex user creates new project the program > should crate the project structure with chapters, asigned users, users > tasks,.. And this functionality does not belong to the Publex.Core.DB > part. Am I right? Do we need to create this classes inside PubleX.PDE ?? > > Regards, > harnas > |
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-02-02 22:01:57
|
Hi,
I've been busy for the last few days (end of semester, exams, etc..).
But now I'm back :) and I have a question about DB part of publex.
The database of every project will contain at least 3 tables:
1) TbProject
- PName
- PUsers (form TbUsers)
- PDocuments (from TbDocument)
- other fields (start date, end date, chapters, ..)
2) TbUsers
- UName
- ULevel
- UProject (from TbProject)
ULevel:
- PM
- ProjectEditor
- PublicationControl
3) TbDocument
- DName
- DProject (from TbProject)
- DChapter
... - document contents..
It's obvious that we need some classes describing our project structure.
There is one class: PubleX.PDE.Document but it does not have all the
fields needed by db. When Publex user creates new project the program
should crate the project structure with chapters, asigned users, users
tasks,.. And this functionality does not belong to the Publex.Core.DB
part. Am I right? Do we need to create this classes inside PubleX.PDE ??
Regards,
harnas
|
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-01-27 15:15:10
|
Hi, I suggest changing the path for the Mac version to /Users/username/ Library/Application Support/PubleX. This is where most Mac apps store their preferences and stuff like that. Regards Jonas Am 27.01.2007 um 27.01 02:20 schrieb PubleX Developer's Mailing List: > I almost forgot my whole reason for sending that message. > > If anyone finds anything wrong (complaining about missing files or > paths) let me know so I can fix whatever I broke. > > Thanks, > Jason > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV________________________________ > _______________ > Publex-developers mailing list > Pub...@li... > https://lists.sourceforge.net/lists/listinfo/publex-developers |
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-01-27 01:20:54
|
I almost forgot my whole reason for sending that message. If anyone finds anything wrong (complaining about missing files or paths) let me know so I can fix whatever I broke. Thanks, Jason |
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-01-27 01:03:57
|
I have been trying to reconfigure the paths for the services ('logs', 'etc',
'plugins', etc). I'm trying to redesign everything so that it will work
with Windows, Mac OS X (Tiger), and Linux in the following ways:
MS Windows: The folders "logs", "etc", "plugins", and "custom" will reside
within:
C:\Documents and Settings\username\ApplicationData\PubleXDE\...
(This directory is actually returned by the environment variable APPDATA)
Linux: These same folders will reside in:
/home/username/.PubleXDE
(This directory is returned by the $HOME environment variable)
MAC: These directories will reside in
/Users/username/.PubleXDE
(Same deal as with Linux)
In all of the above cases, the name "PubleXDE" is appended to the default
location for standard data storage for any given application. I have chosen
to make this change now so that we will not get too far into the project and
rely upon the directory locations. We cannot be assured that the end user
will have write permissions (or even read permissions) to a subdirectory
under our installation path (Win: C:\Program Files | Linux: /usr/bin/PubleX
| Mac: /usr/bin/PubleX).
In keeping with this ideal, let's try to keep the system calls to a
minimum. This will change heavily when we begin working on the server
component, but for the client, the only environment it will need to be aware
of will be the one listed above.
Jason
|
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-01-25 13:04:28
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=4121569 By: cyqotiq I've already answered this question in the mailing list, but for the sake of having the answer here in the future as well, I will re-post my answer. This was a very good set of questions, and the answers should be available for anyone who needs this information in the future. Actually, you just about hit the mark on everything. The process can really get detailed when you begin describing the precise activities for each person in the documentation process. But I've managed to narrow this down to a necessary three positions. Optionally, when PubleX is installed, it may be installed as a stand-alone (single-user) module, which will use local anonymous DB access. It may also be installed in a group (multi-user) module, where it will require that a server component be pre-installed on a remote machine (or possibly running locally over a virtual machine or some type of VPN. The details of how this will work are still shady right now. The idea is that PubleX may be used to modify a documentation project on a single computer - DB is local - or over a network with multiple clients - DB is managed on a server with write access restricted to just that service. All SQL input/output methods will need to be placed within PubleX.Core.DB (in the PubleXCore project) as classes or interfaces that may be exposed by a server component (a separate EXE project) or by a 'Virtual Server" for stand-alone mode. As far as PubleX itself is concerned, the DB requests should all be the same, regardless of which model is being used. The protocol being used (local direct or remote TCP) will be set in the configuration during installation, and will be modifiable during runtime by the user. This is to allow a single-user mode to be "switched" into a client mode. The three positions I mentioned are as follows: Publication Control, Project Management, and Project Editor. It is possible for all three of these to be the same person, but it's really not recommended. Publication Control - This position is responsible for assigning tasks to users, tracking the document locations and status, and gathering the files to send on to another station. This is where the DB interface for end-users will be used. I'll get into the stations a little later. Project Management - This position is responsible for deciding guide lines for documents, which documents go with which projects (or chapters), and which documents are a higher priority than the others. Project Editor - This is our primary end-user. This person actually edits the files. There will be user levels within this group, but what those user levels are and what they can do will be dependent on what the Project Manger decides. For example, with a technical manual, a certain chapter might be designated as "expert" while another might be designated as 'general'. A level 1 user (lowest level) would only be allowed to work on general documents, while a level 3 (highest level) would be allowed to work on any documents. Of course, there might be more than just 3 levels. That depends on what the Manger decides. Stations are the various "check-points" of a document's life. When the project is first created, the Project Manger sets up all the technical details (assigning documents to chapters, giving the priority for the documents, and getting the basic database ready for use). At this point, the documents are put into play. Editors may check them out. Ideally, the Project Control will be able to assign documents to different editors based on which editors are available for editing and what the user levels for the editors are compared to the status of the document. The editor checks the files out for editing, at which point the file is copied to their machine into a local directory. The database will then mark that file as being "unavailable". When the editor is finished, he will check the file back in, moving his local data back to the server's repository. The database is updated with the new status of the documents and a snapshot of old data is made when the old data is archived. Once all of the edits have been made - this requires several checking in and checking out of the files - and the document is ready for delivery, the Publication Control station will gather all of the documents that pertain to a delivery package - this might be a single chapter, or an entire book. This package is then sent out to whoever is receiving the delivery. Additional stations might be included within this process. It would make things much more difficult to track, but the more we can readily track with the database, the better our program will be. Configuration Management members would then be used to communicate between various stations. Configuration Management and Publication Control might be the same station. This would probably only be used if there were a station for a Technical Editor (someone to correct technical errors and grammar) and/or a Subject Matter Expert to correct the subject matter and make "redline" changes for outdated or incorrect data. In order to fully support all of these stations, PubleX would need to support displaying the XML documents as if it were a PDF or a print preview. Then provide tools for both technical editors and SME stations to make corrections (annotations). These corrections would be sent back to the Publication Control with the document, and the Project Editor would update the documents with these changes. There are a lot of variables in all of this, and there is no way we could provide an interface and tools for every possible station. But if we can meet the main three stations (Pubs Control for assigning editors their work, Project Management for running administrative tasks on the project, and Editors for editing the documents), then we will be fine. Eventually, I would like to also support handling an additional station for Configuration Management, SME, and Technical Editor. But that might very well be version 3 or 4. :) >From this basic overview - and that's all this is... an overview - you can probably get an idea of what the database would be used for. If you have any ideas or suggestions, I'm open to hear them. If you have any questions, let me know. Jason ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=645437 |
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-01-24 05:39:51
|
I've committed the changes to te new project XmlUIDev. This project is the first PubleX plugin. It's a MenuPlugin object, so it can be accessed on the "Tools" > "Addins" > "XML UI Designer" menu. It's really rough right now, but it does work for the basic layout design of windows with common controls. It doesn't save anything out to XML yet, but that will be the next step. Right now, I'm trying to clean up the redrawing of the controls and the update of properties. When you update properties, you have to either resize the control or switch windows to force the control to update on screen. Once I get the graphics work cleaned up a bit, I will work on exporting the designed window to an XUI file and being able to load an XUI file into the designer. When this is working, then we'll have our XUI loader, and the toolbar should work. This is what's causing the message box you get when you execute the program. Jason |
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-01-24 02:54:45
|
Actually, you just about hit the mark on everything. The process can really get detailed when you begin describing the precise activities for each person in the documentation process. But I've managed to narrow this down to a necessary three positions. Optionally, when PubleX is installed, it may be installed as a stand-alone (single-user) module, which will use local anonymous DB access. It may also be installed in a group (multi-user) module, where it will require that a server component be pre-installed on a remote machine (or possibly running locally over a virtual machine or some type of VPN. The details of how this will work are still shady right now. The idea is that PubleX may be used to modify a documentation project on a single computer - DB is local - or over a network with multiple clients - DB is managed on a server with write access restricted to just that service. All SQL input/output methods will need to be placed within PubleX.Core.DB(in the PubleXCore project) as classes or interfaces that may be exposed by a server component (a seperate EXE project) or by a 'Virtual Server" for stand-alone mode. As far as PubleX itself is concerned, the DB requests should all be the same, regardless of which model is being used. The protocol being used (local direct or remote TCP) will be set in the configuration during installation, and will be modifyable during runtime by the user. This is to allow a single-user mode to be "switched" into a client mode. The three positions I mentioned are as follows: Publication Control, Project Mangement, and Project Editor. It is possible for all three of these to be the same person, but it's really not recommended. Publication Control - This position is responsible for assigning tasks to users, tracking the document locations and status, and gathering the files to send on to another station. This is where the DB interface for end-users will be used. I'll get into the stations a little later. Project Management - This position is responsible for deciding guide lines for documents, which documents go with which projects (or chapters), and which documents are a higher priority than the others. Project Editor - This is our primary end-user. This person actually edits the files. There will be user levels within this group, but what those user levels are and what they can do will be dependant on what the Project Manger decides. For example, with a technical manual, a certain chapter might be designated as "expert" while another might be designated as 'general'. A level 1 user (lowest level) would only be allowed to work on general documents, while a level 3 (highest level) would be allowed to work on any documents. Of course, there might be more than just 3 levels. That depends on what the Manger decides. Stations are the various "check-points" of a document's life. When the project is first created, the Project Manger sets up all the technical details (assigning documents to chapters, giving the priority for the documents, and getting the basic database ready for use). At this point, the documents are put into play. Editors may check them out. Ideally, the Project Control will be able to assign documents to different editors based on which editors are available for editing and what the user levels for the editors are compared to the status of the document. The editor checks the files out for editing, at which point the file is copied to their machine into a local directory. The database will then mark that file as being "unavailable". When the editor is finished, he will check the file back in, moving his local data back to the server's repository. The database is updated with the new status of the documents and a snapshot of old data is made when the old data is archived. Once all of the edits have been made - this requires several checking in and checking out of the files - and the document is ready for delivery, the Publication Control station will gather all of the documents that pertain to a delivery package - this might be a single chapter, or an entire book. This package is then sent out to whoever is receiving the delivery. Additional stations might be included within this process. It would make things much more difficult to track, but the more we can readily track with the database, the better our program will be. Configuration Management members would then be used to communicate between various stations. Configuration Management and Publication Control might be the same station. This would probably only be used if there were a station for a Technical Editor (someone to correct technical errors and grammar) and/or a Subject Matter Expert to correct the subject matter and make "redline" changes for outdated or incorrect data. In order to fully support all of these stations, PubleX would need to support displaying the XML documents as if it were a PDF or a print preview. Then provide tools for both technical editors and SME stations to make corrections (annotations). These corrections would be sent back to the Publication Control with the document, and the Project Editor would update the documents with these changes. There are a lot of variables in all of this, and there is no way we could provide an interface and tools for every possible station. But if we can meet the main three stations (Pubs Control for assigning editors their work, Project Mangement for running administrative tasks on the project, and Editors for editing the documents), then we will be fine. Eventually, I would like to also support handling an additional station for Configuration Management, SME, and Technical Editor. But that might very well be version 3 or 4. :) >From this basic overview - and that's all this is... an overview - you can probably get an idea of what the database would be used for. If you have any ideas or suggestions, I'm open to hear them. If you have any questions, let me know. Jason |
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-01-23 22:29:14
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=4118792 By: harnas83 Hi, I'm thinking about the database layer of publex, and I have some questions.. First of all, the DB functionality. As far as I understand, the DB will store the documents (so we need to be able to send those files to DB and get them to clients) this functionality is simply implemented using Microsoft.Data.SqlXml class. Second thing is authentication and authorization. How will publex menage this matter? Will it use some general authentication for each client instance (and then the DB access will allow anonymous users) or there will be separate class (and DB table) for manageing users acounts. Version controling. We were talking about it on IRC chanel: cyqotiq: "various people use this program to work on a single Documentation project, someone will need to be a document control person. This person will need to know where any given document is at any given time". So my guess is that publex will use some kind of copy-modify-merge model. User makes a copy of project files to his local drive the DB registers which user is working on which file (so the "document control person" knows what is going on) and previously copyed files not saved back to DB are marked out-of-date. I just started thinking about this, so if I'm completely wrong I would appreciate your insights. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=645437 |
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-01-21 12:19:46
|
Ok, I suggest creating a PubleX.Core.Xml namespace for the front-end and PubleX.Core.Xml.Filters for all the filters, which could base on an IFilter interface. Jonas Am 21.01.2007 um 21.01 08:23 schrieb PubleX Developer's Mailing List: > In regards to the XML front-end, we have two places where it would > fit. I already have a document class in PubleX/Classes/Document.cs > that will handle the opening of XML files. This would be a nice > place for the XML front-end to be used. However, since this is > something that might need to be accessible from outside of the > PubleX main program (such as from within a Plugin), I think it > would be better to write the front-end inside of the PubleX.Core > project. I'm trying to keep all of the "helper" classes there. So > far, I've put the Settings Service, the RegEx tool, a Collections > helper object (ItemPair<T1,T2> - just a storage for two associated > objects of arbitrary types), and the Language tools into the > PubleX.Core project. I think as much of the XML-loading functions > as possible should go here as well. It might be necessary for a > script to load an XML form later. > > ~~Jason > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV________________________________ > _______________ > Publex-developers mailing list > Pub...@li... > https://lists.sourceforge.net/lists/listinfo/publex-developers |
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-01-21 07:23:03
|
In regards to the XML front-end, we have two places where it would fit. I already have a document class in PubleX/Classes/Document.cs that will handle the opening of XML files. This would be a nice place for the XML front-end to be used. However, since this is something that might need to be accessible from outside of the PubleX main program (such as from within a Plugin), I think it would be better to write the front-end inside of the PubleX.Core project. I'm trying to keep all of the "helper" classes there. So far, I've put the Settings Service, the RegEx tool, a Collections helper object (ItemPair<T1,T2> - just a storage for two associated objects of arbitrary types), and the Language tools into the PubleX.Core project. I think as much of the XML-loading functions as possible should go here as well. It might be necessary for a script to load an XML form later. ~~Jason |
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-01-20 23:17:56
|
cool :) Am 21.01.2007 um 21.01 00:16 schrieb PubleX Developer's Mailing List: > I got it that time. > > On 1/20/07, PubleX Developer's Mailing List <publex- > dev...@li... > wrote: > hi > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Publex-developers mailing list > Pub...@li... > https://lists.sourceforge.net/lists/listinfo/publex-developers > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV________________________________ > _______________ > Publex-developers mailing list > Pub...@li... > https://lists.sourceforge.net/lists/listinfo/publex-developers |
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-01-20 23:16:02
|
I got it that time. On 1/20/07, PubleX Developer's Mailing List < pub...@li...> wrote: > > hi > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Publex-developers mailing list > Pub...@li... > https://lists.sourceforge.net/lists/listinfo/publex-developers > |
|
From: PubleX Developer's M. L. <pub...@li...> - 2007-01-20 23:15:35
|
hi |
|
From: Jason S. <jns...@gm...> - 2007-01-17 02:20:47
|
I'm just making sure this is working. I haven't received any of these posts yet. |
|
From: Jason S. <jns...@gm...> - 2007-01-17 02:17:34
|
I've almost got the SharpDevelop code converted into a stripped-down version
that will work with PubleX. In doing so, I've managed to tear the
SharpDevelop code apart and gain a better understanding behind why and how
the constructed it the way the did. This leads me to something of a
problem. I thought I'd pose this question in an open form to see what you
think.
At this point, we have two options. Option 1 is to continue forward and use
what I've stripped down, possibly only using much of it once and creating
our own classes and interfaces from here on forward. Option 2 is to
reconstruct the SharpDevelop code and only strip out the debugging and
compiling support and use the XmlEditor as the native TextEditorControl
instead of a generic TextEditorControl (as it is in SharpDevelop). The
benefit of option1 is that we can get started on writing our own code very
soon, and we will have a ground-up understanding of how it works. The
benefit of option 2 is that most of what we'll need has already been done in
SharpDevelop, and we simply need to add support for advanced functionality
with XML/HTML/SGML and exporting to PDF/DOC/Postscript. We would also need
to add the customized CVS, security (for TCP/IP communications), and
document tracking (SQL). We would have a functional Alpha-stage product
quicker by reusing the bulk of SharpDevelop's code (option 2), but anyone
who helps with the development would need to get to know the code.
For the sake of understanding, I'll provide a list of the more common
classes in the existing SharpDevelop code with a brief description of each
one. If you've already looked into all of this before, then I appologize.
SharpDevelop is broken into 3 main sections. These are the Addins,
Libraries, and the Main code segments. Each of these breaks down further as
follows:
####################
Addins - Some of this code is unnecessary for SharpDevelop to work properly
and can be omitted completely.
######
* Backend Addins - This handles backend bindings (code formatting,
language-specific options, code completion, etc) for various programming
languages (C#, Boo, VB.NET, ILAsm) - This can more or less be dropped.
* Display Binding Addins - Provides the Form Designer, Resource Editor, and
XmlEdit windows. (This is the XmlEditor that I've been trying to use)
* Miscellaneous Addins - Various other addins that provide debugging, addin
management, file type registeration with Windows, highlighting, HtmlHelp,
Mono interfaces, PInvoke management, RegularExpressions toolkit, SharpQuery
(#SQL), the StartPage, and Unit Testing. Several of these addins could be
useful to PubleX.
####################
Libraries - Most of this code can remain as it is
#########
* Build Tasks - Handles compiling projects through .NET, Mono, reading ILASM
assemblies, locating and exposing the Global Cache, and other higher-level
Assembly related features. This can be replaced by our publishing engine.
* TextEditor - This provides the SharpDevelop generic text editor. We've
seen this before.
* NRefactory - Handles parsing using a customized Parser and Lexer class, as
well as getting the output from these classes. This will basically be our
engine for parsing and validating markup langauges.
* WinFormsUI - This handles subclassing Windows controls (
System.Windows.Forms namespace) and exposing some "high-tech" professional
style controls from them. Useful to PubleX.
####################
Main - Most of these sections will be modified to be specific to PubleX
####
* Core - This code handles creating the Addin Manager, Core Services, and
Utilities
- AddIn Manager - This creates a collection of addins, and maintains
properties that determine if they should be loaded or not. This also
exposes the Addins project above.
- Services - This code allows addins and native SharpDevelop classes to
manipulate files managed by the Core library, logging, menus, messaging (to
the user), property creation and retrieval, resources, string parsing
(formatted text), and toolbars
- Util - Provides interfaces for handling commands between SharpDevelop
and Addins, Clipboard management, and Right-To-Left language support
* SharpDevelop - This code provides interfaces to SharpDevelop-specific
areas.
- Commands - Provides interfaces for executing SharpDevelop-related tasks
such as Autostart, Building, Configuration, Layout, Strings, Debugging,
Editing, Files, Menus, TabStrips, Help commands, SideBars, Tools, and
Windows
- DOM - Document-related interfaces to Classes, Code Completion,
Expressions, File editing, Code Folding, Attributes, Comments, Syntax
Highlighting, members, Fields, Methods, parameters, parsing, language (C#,
VB.NET, etc) properties, regions, tags, and XML documentation (such as the
/// <summary>...</summary>)
- GUI - Provides construction and management for XML Forms (XML UI in
PubleX), Workbenches (the main SharpDevelop window), ViewContent (the text
area of an editor control), tree grids, various dialogs
- Internal - Code related to internal SharpDevelop functions: conditional
evaluators, doozers ("builders"), managing exteral tools, templates,
Undo/Redo
- Project - Manages Projects, solutions, and interacts with the Build
Tasks library from above.
- Services - Manages services that handle browsing classes, debugging,
file information and functions, language (English, German, Spanish, etc),
parsing, project loading/saving, refactorization (this would be good for
managing links dynamically), status bar messages, icon resources
- TextEditor - This would be modified for PubleX to handle XML/HTML/SGML
instead of C# or VB.NET code, but the rest of the functionality would stay
this same. This code manages the TextEditorControl and handles bookmarks,
code folding, highlighting, search/replace, encoding, formatting... almost
anything related to TextEditor that is specific to SharpDevelop (the
application).
- Util - Handles interaction between SharpDevelop and external tools
* Startup - This provides the entry point Main() function for the
application. This code is responsible for initializing the rest of the
code.
------------------------------------------------------
Having said all of that, I know it's a lot to read, but that's the rough
break-down of what lies within the SharpDevelop code. As you can see, a
LARGE portion of this code can be reused by PubleX... much of it as-is. So
what do you think we should do? Should we go ahead and make use of as much
of the project as we can, and use the SharpDevelop AddIn manager,
XmlEditor/Styler, #SQL, Property Management, XML Forms, Messaging/Logging
Services, and then just modify the Project classes to support our own
customized "Project"?
If we decide to go this route, then the Solution/Project relationship can
still be maintained. An XML instance would be a "Project". This would
include the XML file, any stylesheets, graphics, and other external files
required to display or print that XML file. It would also include files
that aren't necessary, but are relevant to an instance, such as comment
pages or notes. All of the instances together that made up a manual or
document collection would be the same as a Solution. Instead of compiling
the code into a binary file, the "Build" functions would collect all of the
instances together and create a publishing package... which would then be
compressed, burned to a CD, printed, or placed off into a directory to await
further action.
The two largest components that we would need to build to have a functional
demonstration would be task tracking (the database and tracking "who has
what") and the CVS system.
So what do you think?
|
|
From: Jason S. <jns...@gm...> - 2007-01-16 07:00:37
|
So far, the project has had quite a bit added to it. I will try to cover the important points here, but I'm sure I'll forget something. * PubleXCore Project - This project will handle the inner workings of PubleX. It encapsulates the plugin manager, DOM interfaces, an incomplete build manager for publishing, and several services that manage file and path manipulation, logging, application-to-user messaging, property management, string parsing, and resource management. * Security - This project contains much from the SharpZipLib with several features added. The Blowfish encryption algorithm has been added, as well as a customized version of Blowfish of my own that makes use of key strengthening and stream compression using BZip2. A newer version of the library that Security is based upon also contains unfinished code that will handle creation and reading of ISO images and Microsoft CAB files. * PubleXImageLib - This library will manage the images used for toolbars, menus, icons, and other general image resources for PubleX. * XmlEditor - This library is LARGELY incomplete. It is the primary reason why the PubleXCore library has been created. Once finished, this library will handle the parsing and display of XML files. Of particular note, while implementing PubleXCore, I have found various useful functions to track program options through the Property classes. These classes are used heavily within PubleXCore, and can easily be exposed within PubleX. The LoggingService is also something that can easily be exposed from within PubleX. This service handles dumping errors, warnings, information, and debugging info to a formatted HTML file that can be viewed as-is in a browser. It can also be sent to the developers for debugging purposes. The resource manager isn't 100% compliant to our project, but works as-is nonetheless. PubleX can be modified slightly to make use of this service so that we can fully support the multi-language interface and make PubleX as professional and muli-lingual as possible. The resources can also be in the form of settings, along with the use of the PropertyService. The Build class is more-or-less empty at this point. This class will be responsible for calling delegates within PubleX itself in order to build (publish) single XML files or multiple files. This can come in handy for both "building" the sub-version package that gets sent back to the server after editing, as well as publishing an entire project into one of the supported formats. Most of the work will be done within PubleX, but the Build class will allow the PubleXCore library to call these functions so that there is some type of order maintained during this process. The PluginTree manages the loading and exposition of plugins for PubleX. The design is much more in-depth that the one previously used. It might be worth while to read the Plugin codes to gain a complete understanding of the functions performed by this section of the library. As of this time, the project does not compile. Several features within PubleXCore must be completed before this can happen. PubleXCore is the pivotal point behind the entire project. Without a functional core, the rest is useless. |
|
From: Jason S. <jns...@gm...> - 2007-01-15 23:08:18
|
testing 1, 2, 3 |
|
From: Johnathan A. <cyp...@ya...> - 2007-01-15 23:05:56
|
testing ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. |
|
From: Johnathan A. <cyp...@ya...> - 2007-01-15 21:53:50
|
After evaluating several options, I believe I've found a viable solution to serveral problems. Problem #1: Microsoft XML (.NET) does not support processing instructions that begin with <?xml...> Solution: Find an alternative XML parser/validator Problem #2: The editor (XML/SGML/HTML) should support syntax highlighting and code folding for markup nodes. Solution: Use a freely available text editor that supports these features. Problem #3: In order to keep the source code to a minimum, as much as is possible of the above elements needs to be streamlined to be native to this project. Solution: See next paragraph. To solve these problems, the project has turned to using the SharpDevelop TextEditor control. This control has built-in support for code-folding as well as XML highlighting. The XML-based highlighting and folding will also lend support to highlighting and folding for SGML and HTML as well, since it's theoretically possible to implement either of these languages within XML (with a few minor adjustments such as requiring closing </p> for HTML and requiring the ending ?> for PIs in SGML). This leaves only a single problem to be solved. XML parsing is not an easy task, but it appears that our friends at ICSharpCode have taken this task and produced a rather thorough way of tackling this problem. By supporting generic language tools by which to implement any parsible language within SharpDevelop, they have also created a means by which XML (or any structured language) can be highlighted and/or code-folded within their TextEditor control. The solution applies to this project by taking the actions outlined within this post and re-implementing a tailored version of their code that fits in nicely with PubleX. Before any code may be implemented from the SharpDevelop project, a new directory structure will need to be created within PubleX so that navigating the file tree will be as painless as possible. This will require some major "house cleaning" in order for this to work. So I am asking that all developers stop any CVS editing until this can be done. The main file (EditorWindow.cs) that exists now will continue to exist within the UI folder, so any edits to this folder will be permissible, however structural changes to the dependancies may very well change (and break existing code until it can be repaired). With this in mind, it would be in the best interest of the project that no edits be made until after this house cleaning has taken place. I will be working through this week to see that this happens so that the ICSharpCode modules can be tailored to fit our project. I am only awaiting a reply from the ICSharpCode team before I take on this task. Until then, we will still be taking any suggestions and minor modifications to the UI itself. The XML UI modules may also be implemented, provided that the parsing is left as generic as possible so as to make use of our own customized parser after the ICSharpCode modules have been put in place. Sorry for the interruption, but I think that this is the best time to do this, since as of the time of this writing there are only two developers on this project. :) ~~Jason ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 |
|
From: Johnathan A. <cyp...@ya...> - 2007-01-15 15:08:27
|
____________________________________________________________________________________ TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ |
