Tiki Wiki CMS Groupware

Several features are still to be desired in file galleries. Among others, alternate storage engines, using file galleries for attachments across Tiki and customizable views may be desired. Some features are partially available, like uploading files ... [More] to public locations to avoid the overhead of permission checking for files part of the site. In order to see what was possible and explore the current code, some low level refactoring was performed and included: Conversion of simple SQL queries to helper functions Replacement of low level file access for higher level functionalities available in PHP5 Extraction of common patterns to functions to remove duplication Extract file gallery related functions from tikilib Extract some logic from root PHP files to the libraries These changes left the code in a substancially better condition, leaving the library at just over 3000 lines of code. However, the process highlighted several flaws: Incorrect handling of file upload Depending on which entry point is used, different validation and handling may be used File validation relies mostly on what is provided by the browser (mime type, extension) rather than inspecting the file Exceptions are hard-coded (and arbitrary) rather than configured Lack of design Some valid handling was coded for a narrow use case rather than being generalized. Confusion between view and storage Confusion between file and metadata Less code paths These multiple factors lead to inconsistencies in how Tiki behaves, breaking user expectations. Cleaner rules are needed to identify which files are valid and where they should be stored. One of the major issues while refactoring was the widely duplicate condiitions to identify where podcast gallery files should be stored. While this is mostly resolved at this time, there are other cases where this occurs, and other conditions where it should. There are multiple entry points which are unavoidable and desired, including file upload, batch upload, attachment upload, webdav upload, batch import from directory, and such. Right now, each of those handles the full path to the storage. The initial refactoring brought some helpers to handle common parts, but the differences in handling could not be unified without breaking some existing behavior, no matter how wrong they are. The code needs to transition to a state where only the input is identified and then moved along to a single code path to handle validation: Identify input as a wrapper Identify destination Collect file information (using fileinfo when available) Perform validation Store the file and reference Store meta-data (Optionally) Post-processing Fill missing meta-data (default names and such) Index content Handle various notifications, watches, ... This transition is a significant refactoring effort that will lead to some rules to some validation rules to change. Re-think purposes File galleries serve multiple purposes at this time. They define physical properties of the galleries such as the amount of files that can be contained, disk quotas, wether revision will be kept and depending on the gallery type, where files will be stored. They define view properties such as the thumbnail size, displayed information and templates. They serve as the primary purpose of navigation through the hierarchy, replicating a typical filesystem. All of these concepts serve different users and could be maintained separately. By using categories as the means for organization and navigation, a regular filesystem could be replicated, except that files could naturally live in multiple locations to serve different navigation requirements. The user would simply select the desired view, like a thumbnail view, just like it is done in operating systems. These views could be configured by administrators, but would remain independent from the individual galleries. This would leave the physical properties to file galleries, leaving them as mere partitions determining where files are stored and the available capacity, a tool for administrators to handle system requirements. Files could be migrated between galleries over time without affecting the navigation. For example, old files that are not accessed frequently could be stored on a remote SAN with slower access times, but higher storage capacity. Public files could be stored directly in a gallery where the directory is web-accessible, avoiding the PHP overhead for images on the site. By detecting this at link creation, the correct link could be built when using the appropriate plugin. This model is a significant change from the current implementation and is not without migration challenges. One of the earliest changes that could be performed is around removing the view properties from the galleries and introducing a separate view concept. To combine with the effort to reduce the amount of code paths, the file gallery should probably optionally define a location to store files, removing this condition that is currently based on the file type. Just files One aspect where different decisions in the code must be made is around all of the meta-data surrounding files. When uploading a single file, adding a name and description field comes in naturally, but when uploading multiple files are uploaded or files are uploaded without a form, those gaps are left empty and different behaviors may be used. More broadly, a user may question the very use of having a different name and a description. Once the content is indexed, those serve a much smaller purpose. Depending on the usage, alternate meta-data may be preferable altogether. The files should only contain the file relevant to the file itself. Other properties could be deferred to trackers, perhaps using specific values per file type. If tracker attachments were stored in file galleries and benefited from the complete indexing capabilities, the result with separated concerns would not be much different. Files that do not need meta-data could simply use file galleries, those that do would go through trackers. Some user interface could be added to attach meta-data to an existing file, essentially creating a new tracker item and automatically adding the attachment. Similarly, other attachments could be treated the same way. In order to make the attachments available through WebDAV, some category synchronization between the container object and the attachment would be required, or at least user interfaces to allow selecting them. [Less]

Several features are still to be desired in file galleries. Among others, alternate storage engines, using file galleries for attachments across Tiki and customizable views may be desired. Some features are partially available, like uploading files ... [More] to public locations to avoid the overhead of permission checking for files part of the site. In order to see what was possible and explore the current code, some low level refactoring was performed and included: Conversion of simple SQL queries to helper functions Replacement of low level file access for higher level functionalities available in PHP5 Extraction of common patterns to functions to remove duplication Extract file gallery related functions from tikilib Extract some logic from root PHP files to the libraries These changes left the code in a substancially better condition, leaving the library at just over 3000 lines of code. However, the process highlighted several flaws: Incorrect handling of file upload Depending on which entry point is used, different validation and handling may be used File validation relies mostly on what is provided by the browser (mime type, extension) rather than inspecting the file Exceptions are hard-coded (and arbitrary) rather than configured Lack of design Some valid handling was coded for a narrow use case rather than being generalized. Confusion between view and storage Confusion between file and metadata Less code paths These multiple factors lead to inconsistencies in how Tiki behaves, breaking user expectations. Cleaner rules are needed to identify which files are valid and where they should be stored. One of the major issues while refactoring was the widely duplicate condiitions to identify where podcast gallery files should be stored. While this is mostly resolved at this time, there are other cases where this occurs, and other conditions where it should. There are multiple entry points which are unavoidable and desired, including file upload, batch upload, attachment upload, webdav upload, batch import from directory, and such. Right now, each of those handles the full path to the storage. The initial refactoring brought some helpers to handle common parts, but the differences in handling could not be unified without breaking some existing behavior, no matter how wrong they are. The code needs to transition to a state where only the input is identified and then moved along to a single code path to handle validation: Identify input as a wrapper Identify destination Collect file information (using fileinfo when available) Perform validation Store the file and reference Store meta-data (Optionally) Post-processing Fill missing meta-data (default names and such) Index content Handle various notifications, watches, ... This transition is a significant refactoring effort that will lead to some rules to some validation rules to change. Re-think purposes File galleries serve multiple purposes at this time. They define physical properties of the galleries such as the amount of files that can be contained, disk quotas, wether revision will be kept and depending on the gallery type, where files will be stored. They define view properties such as the thumbnail size, displayed information and templates. They serve as the primary purpose of navigation through the hierarchy, replicating a typical filesystem. All of these concepts serve different users and could be maintained separately. By using categories as the means for organization and navigation, a regular filesystem could be replicated, except that files could naturally live in multiple locations to serve different navigation requirements. The user would simply select the desired view, like a thumbnail view, just like it is done in operating systems. These views could be configured by administrators, but would remain independent from the individual galleries. This would leave the physical properties to file galleries, leaving them as mere partitions determining where files are stored and the available capacity, a tool for administrators to handle system requirements. Files could be migrated between galleries over time without affecting the navigation. For example, old files that are not accessed frequently could be stored on a remote SAN with slower access times, but higher storage capacity. Public files could be stored directly in a gallery where the directory is web-accessible, avoiding the PHP overhead for images on the site. By detecting this at link creation, the correct link could be built when using the appropriate plugin. This model is a significant change from the current implementation and is not without migration challenges. One of the earliest changes that could be performed is around removing the view properties from the galleries and introducing a separate view concept. To combine with the effort to reduce the amount of code paths, the file gallery should probably optionally define a location to store files, removing this condition that is currently based on the file type. Just files One aspect where different decisions in the code must be made is around all of the meta-data surrounding files. When uploading a single file, adding a name and description field comes in naturally, but when uploading multiple files are uploaded or files are uploaded without a form, those gaps are left empty and different behaviors may be used. More broadly, a user may question the very use of having a different name and a description. Once the content is indexed, those serve a much smaller purpose. Depending on the usage, alternate meta-data may be preferable altogether. The files should only contain the file relevant to the file itself. Other properties could be deferred to trackers, perhaps using specific values per file type. If tracker attachments were stored in file galleries and benefited from the complete indexing capabilities, the result with separated concerns would not be much different. Files that do not need meta-data could simply use file galleries, those that do would go through trackers. Some user interface could be added to attach meta-data to an existing file, essentially creating a new tracker item and automatically adding the attachment. Similarly, other attachments could be treated the same way. In order to make the attachments available through WebDAV, some category synchronization between the container object and the attachment would be required, or at least user interfaces to allow selecting them. [Less]

Several features are still to be desired in file galleries. Among others, alternate storage engines, using file galleries for attachments across Tiki and customizable views may be desired. Some features are partially available, like uploading files ... [More] to public locations to avoid the overhead of permission checking for files part of the site. In order to see what was possible and explore the current code, some low level refactoring was performed and included: Conversion of simple SQL queries to helper functions Replacement of low level file access for higher level functionalities available in PHP5 Extraction of common patterns to functions to remove duplication Extract file gallery related functions from tikilib Extract some logic from root PHP files to the libraries These changes left the code in a substancially better condition, leaving the library at just over 3000 lines of code. However, the process highlighted several flaws: Incorrect handling of file upload Depending on which entry point is used, different validation and handling may be used File validation relies mostly on what is provided by the browser (mime type, extension) rather than inspecting the file Exceptions are hard-coded (and arbitrary) rather than configured Lack of design Some valid handling was coded for a narrow use case rather than being generalized. Confusion between view and storage Confusion between file and metadata Less code paths These multiple factors lead to inconsistencies in how Tiki behaves, breaking user expectations. Cleaner rules are needed to identify which files are valid and where they should be stored. One of the major issues while refactoring was the widely duplicate condiitions to identify where podcast gallery files should be stored. While this is mostly resolved at this time, there are other cases where this occurs, and other conditions where it should. There are multiple entry points which are unavoidable and desired, including file upload, batch upload, attachment upload, webdav upload, batch import from directory, and such. Right now, each of those handles the full path to the storage. The initial refactoring brought some helpers to handle common parts, but the differences in handling could not be unified without breaking some existing behavior, no matter how wrong they are. The code needs to transition to a state where only the input is identified and then moved along to a single code path to handle validation: Identify input as a wrapper Identify destination Collect file information (using fileinfo when available) Perform validation Store the file and reference Store meta-data (Optionally) Post-processing Fill missing meta-data (default names and such) Index content Handle various notifications, watches, ... This transition is a significant refactoring effort that will lead to some rules to some validation rules to change. Re-think purposes File galleries serve multiple purposes at this time. They define physical properties of the galleries such as the amount of files that can be contained, disk quotas, wether revision will be kept and depending on the gallery type, where files will be stored. They define view properties such as the thumbnail size, displayed information and templates. They serve as the primary purpose of navigation through the hierarchy, replicating a typical filesystem. All of these concepts serve different users and could be maintained separately. By using categories as the means for organization and navigation, a regular filesystem could be replicated, except that files could naturally live in multiple locations to serve different navigation requirements. The user would simply select the desired view, like a thumbnail view, just like it is done in operating systems. These views could be configured by administrators, but would remain independent from the individual galleries. This would leave the physical properties to file galleries, leaving them as mere partitions determining where files are stored and the available capacity, a tool for administrators to handle system requirements. Files could be migrated between galleries over time without affecting the navigation. For example, old files that are not accessed frequently could be stored on a remote SAN with slower access times, but higher storage capacity. Public files could be stored directly in a gallery where the directory is web-accessible, avoiding the PHP overhead for images on the site. By detecting this at link creation, the correct link could be built when using the appropriate plugin. This model is a significant change from the current implementation and is not without migration challenges. One of the earliest changes that could be performed is around removing the view properties from the galleries and introducing a separate view concept. To combine with the effort to reduce the amount of code paths, the file gallery should probably optionally define a location to store files, removing this condition that is currently based on the file type. Just files One aspect where different decisions in the code must be made is around all of the meta-data surrounding files. When uploading a single file, adding a name and description field comes in naturally, but when uploading multiple files are uploaded or files are uploaded without a form, those gaps are left empty and different behaviors may be used. More broadly, a user may question the very use of having a different name and a description. Once the content is indexed, those serve a much smaller purpose. Depending on the usage, alternate meta-data may be preferable altogether. The files should only contain the file relevant to the file itself. Other properties could be deferred to trackers, perhaps using specific values per file type. If tracker attachments were stored in file galleries and benefited from the complete indexing capabilities, the result with separated concerns would not be much different. Files that do not need meta-data could simply use file galleries, those that do would go through trackers. Some user interface could be added to attach meta-data to an existing file, essentially creating a new tracker item and automatically adding the attachment. Similarly, other attachments could be treated the same way. In order to make the attachments available through WebDAV, some category synchronization between the container object and the attachment would be required, or at least user interfaces to allow selecting them. [Less]

Several features are still to be desired in file galleries. Among others, alternate storage engines, using file galleries for attachments across Tiki and customizable views may be desired. Some features are partially available, like uploading files ... [More] to public locations to avoid the overhead of permission checking for files part of the site. In order to see what was possible and explore the current code, some low level refactoring was performed and included: Conversion of simple SQL queries to helper functions Replacement of low level file access for higher level functionalities available in PHP5 Extraction of common patterns to functions to remove duplication Extract file gallery related functions from tikilib Extract some logic from root PHP files to the libraries These changes left the code in a substancially better condition, leaving the library at just over 3000 lines of code. However, the process highlighted several flaws: Incorrect handling of file upload Depending on which entry point is used, different validation and handling may be used File validation relies mostly on what is provided by the browser (mime type, extension) rather than inspecting the file Exceptions are hard-coded (and arbitrary) rather than configured Lack of design Some valid handling was coded for a narrow use case rather than being generalized. Confusion between view and storage Confusion between file and metadata Less code paths These multiple factors lead to inconsistencies in how Tiki behaves, breaking user expectations. Cleaner rules are needed to identify which files are valid and where they should be stored. One of the major issues while refactoring was the widely duplicate condiitions to identify where podcast gallery files should be stored. While this is mostly resolved at this time, there are other cases where this occurs, and other conditions where it should. There are multiple entry points which are unavoidable and desired, including file upload, batch upload, attachment upload, webdav upload, batch import from directory, and such. Right now, each of those handles the full path to the storage. The initial refactoring brought some helpers to handle common parts, but the differences in handling could not be unified without breaking some existing behavior, no matter how wrong they are. The code needs to transition to a state where only the input is identified and then moved along to a single code path to handle validation: Identify input as a wrapper Identify destination Collect file information (using fileinfo when available) Perform validation Store the file and reference Store meta-data (Optionally) Post-processing Fill missing meta-data (default names and such) Index content Handle various notifications, watches, ... This transition is a significant refactoring effort that will lead to some rules to some validation rules to change. Re-think purposes File galleries serve multiple purposes at this time. They define physical properties of the galleries such as the amount of files that can be contained, disk quotas, wether revision will be kept and depending on the gallery type, where files will be stored. They define view properties such as the thumbnail size, displayed information and templates. They serve as the primary purpose of navigation through the hierarchy, replicating a typical filesystem. All of these concepts serve different users and could be maintained separately. By using categories as the means for organization and navigation, a regular filesystem could be replicated, except that files could naturally live in multiple locations to serve different navigation requirements. The user would simply select the desired view, like a thumbnail view, just like it is done in operating systems. These views could be configured by administrators, but would remain independent from the individual galleries. This would leave the physical properties to file galleries, leaving them as mere partitions determining where files are stored and the available capacity, a tool for administrators to handle system requirements. Files could be migrated between galleries over time without affecting the navigation. For example, old files that are not accessed frequently could be stored on a remote SAN with slower access times, but higher storage capacity. Public files could be stored directly in a gallery where the directory is web-accessible, avoiding the PHP overhead for images on the site. By detecting this at link creation, the correct link could be built when using the appropriate plugin. This model is a significant change from the current implementation and is not without migration challenges. One of the earliest changes that could be performed is around removing the view properties from the galleries and introducing a separate view concept. To combine with the effort to reduce the amount of code paths, the file gallery should probably optionally define a location to store files, removing this condition that is currently based on the file type. Just files One aspect where different decisions in the code must be made is around all of the meta-data surrounding files. When uploading a single file, adding a name and description field comes in naturally, but when uploading multiple files are uploaded or files are uploaded without a form, those gaps are left empty and different behaviors may be used. More broadly, a user may question the very use of having a different name and a description. Once the content is indexed, those serve a much smaller purpose. Depending on the usage, alternate meta-data may be preferable altogether. The files should only contain the file relevant to the file itself. Other properties could be deferred to trackers, perhaps using specific values per file type. If tracker attachments were stored in file galleries and benefited from the complete indexing capabilities, the result with separated concerns would not be much different. Files that do not need meta-data could simply use file galleries, those that do would go through trackers. Some user interface could be added to attach meta-data to an existing file, essentially creating a new tracker item and automatically adding the attachment. Similarly, other attachments could be treated the same way. In order to make the attachments available through WebDAV, some category synchronization between the container object and the attachment would be required, or at least user interfaces to allow selecting them. [Less]

Several features are still to be desired in file galleries. Among others, alternate storage engines, using file galleries for attachments across Tiki and customizable views may be desired. Some features are partially available, like uploading files ... [More] to public locations to avoid the overhead of permission checking for files part of the site. In order to see what was possible and explore the current code, some low level refactoring was performed and included: Conversion of simple SQL queries to helper functions Replacement of low level file access for higher level functionalities available in PHP5 Extraction of common patterns to functions to remove duplication Extract file gallery related functions from tikilib Extract some logic from root PHP files to the libraries These changes left the code in a substancially better condition, leaving the library at just over 3000 lines of code. However, the process highlighted several flaws: Incorrect handling of file upload Depending on which entry point is used, different validation and handling may be used File validation relies mostly on what is provided by the browser (mime type, extension) rather than inspecting the file Exceptions are hard-coded (and arbitrary) rather than configured Lack of design Some valid handling was coded for a narrow use case rather than being generalized. Confusion between view and storage Confusion between file and metadata Less code paths These multiple factors lead to inconsistencies in how Tiki behaves, breaking user expectations. Cleaner rules are needed to identify which files are valid and where they should be stored. One of the major issues while refactoring was the widely duplicate condiitions to identify where podcast gallery files should be stored. While this is mostly resolved at this time, there are other cases where this occurs, and other conditions where it should. There are multiple entry points which are unavoidable and desired, including file upload, batch upload, attachment upload, webdav upload, batch import from directory, and such. Right now, each of those handles the full path to the storage. The initial refactoring brought some helpers to handle common parts, but the differences in handling could not be unified without breaking some existing behavior, no matter how wrong they are. The code needs to transition to a state where only the input is identified and then moved along to a single code path to handle validation: Identify input as a wrapper Identify destination Collect file information (using fileinfo when available) Perform validation Store the file and reference Store meta-data (Optionally) Post-processing Fill missing meta-data (default names and such) Index content Handle various notifications, watches, ... This transition is a significant refactoring effort that will lead to some rules to some validation rules to change. Re-think purposes File galleries serve multiple purposes at this time. They define physical properties of the galleries such as the amount of files that can be contained, disk quotas, wether revision will be kept and depending on the gallery type, where files will be stored. They define view properties such as the thumbnail size, displayed information and templates. They serve as the primary purpose of navigation through the hierarchy, replicating a typical filesystem. All of these concepts serve different users and could be maintained separately. By using categories as the means for organization and navigation, a regular filesystem could be replicated, except that files could naturally live in multiple locations to serve different navigation requirements. The user would simply select the desired view, like a thumbnail view, just like it is done in operating systems. These views could be configured by administrators, but would remain independent from the individual galleries. This would leave the physical properties to file galleries, leaving them as mere partitions determining where files are stored and the available capacity, a tool for administrators to handle system requirements. Files could be migrated between galleries over time without affecting the navigation. For example, old files that are not accessed frequently could be stored on a remote SAN with slower access times, but higher storage capacity. Public files could be stored directly in a gallery where the directory is web-accessible, avoiding the PHP overhead for images on the site. By detecting this at link creation, the correct link could be built when using the appropriate plugin. This model is a significant change from the current implementation and is not without migration challenges. One of the earliest changes that could be performed is around removing the view properties from the galleries and introducing a separate view concept. To combine with the effort to reduce the amount of code paths, the file gallery should probably optionally define a location to store files, removing this condition that is currently based on the file type. Just files One aspect where different decisions in the code must be made is around all of the meta-data surrounding files. When uploading a single file, adding a name and description field comes in naturally, but when uploading multiple files are uploaded or files are uploaded without a form, those gaps are left empty and different behaviors may be used. More broadly, a user may question the very use of having a different name and a description. Once the content is indexed, those serve a much smaller purpose. Depending on the usage, alternate meta-data may be preferable altogether. The files should only contain the file relevant to the file itself. Other properties could be deferred to trackers, perhaps using specific values per file type. If tracker attachments were stored in file galleries and benefited from the complete indexing capabilities, the result with separated concerns would not be much different. Files that do not need meta-data could simply use file galleries, those that do would go through trackers. Some user interface could be added to attach meta-data to an existing file, essentially creating a new tracker item and automatically adding the attachment. Similarly, other attachments could be treated the same way. In order to make the attachments available through WebDAV, some category synchronization between the container object and the attachment would be required, or at least user interfaces to allow selecting them. [Less]

Several features are still to be desired in file galleries. Among others, alternate storage engines, using file galleries for attachments across Tiki and customizable views may be desired. Some features are partially available, like uploading files ... [More] to public locations to avoid the overhead of permission checking for files part of the site. In order to see what was possible and explore the current code, some low level refactoring was performed and included: Conversion of simple SQL queries to helper functions Replacement of low level file access for higher level functionalities available in PHP5 Extraction of common patterns to functions to remove duplication Extract file gallery related functions from tikilib Extract some logic from root PHP files to the libraries These changes left the code in a substancially better condition, leaving the library at just over 3000 lines of code. However, the process highlighted several flaws: Incorrect handling of file upload Depending on which entry point is used, different validation and handling may be used File validation relies mostly on what is provided by the browser (mime type, extension) rather than inspecting the file Exceptions are hard-coded (and arbitrary) rather than configured Lack of design Some valid handling was coded for a narrow use case rather than being generalized. Confusion between view and storage Confusion between file and metadata Less code paths These multiple factors lead to inconsistencies in how Tiki behaves, breaking user expectations. Cleaner rules are needed to identify which files are valid and where they should be stored. One of the major issues while refactoring was the widely duplicate condiitions to identify where podcast gallery files should be stored. While this is mostly resolved at this time, there are other cases where this occurs, and other conditions where it should. There are multiple entry points which are unavoidable and desired, including file upload, batch upload, attachment upload, webdav upload, batch import from directory, and such. Right now, each of those handles the full path to the storage. The initial refactoring brought some helpers to handle common parts, but the differences in handling could not be unified without breaking some existing behavior, no matter how wrong they are. The code needs to transition to a state where only the input is identified and then moved along to a single code path to handle validation: Identify input as a wrapper Identify destination Collect file information (using fileinfo when available) Perform validation Store the file and reference Store meta-data (Optionally) Post-processing Fill missing meta-data (default names and such) Index content Handle various notifications, watches, ... This transition is a significant refactoring effort that will lead to some rules to some validation rules to change. Re-think purposes File galleries serve multiple purposes at this time. They define physical properties of the galleries such as the amount of files that can be contained, disk quotas, wether revision will be kept and depending on the gallery type, where files will be stored. They define view properties such as the thumbnail size, displayed information and templates. They serve as the primary purpose of navigation through the hierarchy, replicating a typical filesystem. All of these concepts serve different users and could be maintained separately. By using categories as the means for organization and navigation, a regular filesystem could be replicated, except that files could naturally live in multiple locations to serve different navigation requirements. The user would simply select the desired view, like a thumbnail view, just like it is done in operating systems. These views could be configured by administrators, but would remain independent from the individual galleries. This would leave the physical properties to file galleries, leaving them as mere partitions determining where files are stored and the available capacity, a tool for administrators to handle system requirements. Files could be migrated between galleries over time without affecting the navigation. For example, old files that are not accessed frequently could be stored on a remote SAN with slower access times, but higher storage capacity. Public files could be stored directly in a gallery where the directory is web-accessible, avoiding the PHP overhead for images on the site. By detecting this at link creation, the correct link could be built when using the appropriate plugin. This model is a significant change from the current implementation and is not without migration challenges. One of the earliest changes that could be performed is around removing the view properties from the galleries and introducing a separate view concept. To combine with the effort to reduce the amount of code paths, the file gallery should probably optionally define a location to store files, removing this condition that is currently based on the file type. Just files One aspect where different decisions in the code must be made is around all of the meta-data surrounding files. When uploading a single file, adding a name and description field comes in naturally, but when uploading multiple files are uploaded or files are uploaded without a form, those gaps are left empty and different behaviors may be used. More broadly, a user may question the very use of having a different name and a description. Once the content is indexed, those serve a much smaller purpose. Depending on the usage, alternate meta-data may be preferable altogether. The files should only contain the file relevant to the file itself. Other properties could be deferred to trackers, perhaps using specific values per file type. If tracker attachments were stored in file galleries and benefited from the complete indexing capabilities, the result with separated concerns would not be much different. Files that do not need meta-data could simply use file galleries, those that do would go through trackers. Some user interface could be added to attach meta-data to an existing file, essentially creating a new tracker item and automatically adding the attachment. Similarly, other attachments could be treated the same way. In order to make the attachments available through WebDAV, some category synchronization between the container object and the attachment would be required, or at least user interfaces to allow selecting them. [Less]

It is often criticized that the source code in Tiki is not object-oriented enough. There are several issues this brings up when adapting the code to new needs. Most of which are code duplication, inconsistency in behavior and growing functions with ... [More] loosely coupled concepts. There have been multiple proposals in the past which resulted in little to no results. The following factors may be the cause: Lack of involvement, multiple +1 but no actual actions taken Drastic changes required, effort needed is higher than what anyone can commit to Problem more complex than it appeared, implementation eventually abandoned Implementation essentially done, but not deployed all the way through and left unfinished, rotting into obsolescence To this day, one of the most successful refactoring made in Tiki was the dynamic preferences even if it required a massive effort and extended over multiple releases (hello pkdille!). The reason that lead to success were: Clear benefits to end users (consistency in UI, additional documentation, configuration search) Significant clean-up of the code making it easier for developers too Easy to understand and deploy Can be deployed gradually without causing drawbacks Not all required changes are as easy to deploy and will have as a direct benefit to the end user, but it is almost guaranteed that changes that are purely aesthetic will fail to gain traction. Simply going 'object oriented' won't cut it. Design methods using object oriented are good, but not a holy grail or a goal to aim for. Great design patterns are built and described using object oriented features, but implementing a pattern is not an objective either. Desired properties and behaviors of the code must be identified, than a design can be selected. The classes used as function libraries are not a bad thing in themselves. TikiLib is an issue because it is too large and contains completely unrelated functions, but the other ones provide a good overview to what is available for a given feature. Something that is often crucially missing in well design object oriented libraries. The concept is entrenched in Tiki and thinking it will go away is wishful thinking. The problems lie within those libraries, not in their existence. Tiki should provide better utilities for developers than it does now, but going for a share parent class will only bring back to the same issues we have right now with TikiLib. There are a few common patterns in Tiki that lead to code smell. Targeting those patterns would lead to better code. It may be subtle, but work has begun a long time ago. Listing functions in the libraries have a growing number of arguments. The ordering is only based on the evolution of the function itself. Multiple filters and formatting options appear and cause the hand-built SQL to be low-performing, hard to debug and generally unstable CRUD functionality is essentially composed of a hand-built SQL query. Depending on some preferences, the data may be altered or the operation may be prevented at all. After the actual update of the data, various other operations are performed, like updating indexes, user scores, backlinks, contributions and a whole series of other manipulations. Somewhere in the process, notifications are sent out. The PHP files in the Tiki root simply perform too much work and have no consistency on how tasks are performed. The Unified Search project aims at the listing issue by providing a flexible search index interface allowing for customizable output formatting and advanced filtering. The need for these parameters will be scaled down as we move forward. Perhaps we can begin to remove them. The SQL query building part could easily be solved using database utility methods. It would reduce the amount of errors made and simplify the code. It can easily be deployed over time The pre and post behavior could be triggered through the SignalSlot pattern, allowing external code to hook into the save process without affecting the actual library. A data container could be sent around for the pre hooks to allow them to alter the data or interrupt the chain altogether. The cross-feature behaviors could be registered only once and apply where needed. A drawback of this approach is that the code becomes harder to trace. As there are more dynamic bindings, knowing which pieces of code run becomes more of an issue. To mitigate this, the data container could contain a debug log for the different pieces of code to indicate that they ran and summarize what they did, allowing developers to look into what happened. Forms are always defined in template file. The PHP file then collects the input in a ad-hoc manner, converts the format into what is expected by the library (which is close to the database in most cases). The library then pushes the data to the database. Better facilities are required to collect the data from the request and in many case, the format taken by the library has to be standardized. Just like list functions, the order of the arguments is arbitrary in most cases. Tiki should provide functionality to support form validation, both on the PHP side and on the browser side. This could be done in a number of ways, but could be composed of form field configurations and smarty plugins to include within the forms. The additions should remain a toolkit rather than an obligation to allow for gradual deployment and preserve the flexibility. Preserving the environment is always an issue. Compatibility has to be maintained, expectations must be met. Developers have been used to flexibility in Tiki and any framework that constrains what can be done (remember Magic?) is likely not to gain support. The codebase is large and not everything can be done within a single release cycle. [Less]

It is often criticized that the source code in Tiki is not object-oriented enough. There are several issues this brings up when adapting the code to new needs. Most of which are code duplication, inconsistency in behavior and growing functions with ... [More] loosely coupled concepts. There have been multiple proposals in the past which resulted in little to no results. The following factors may be the cause: Lack of involvement, multiple +1 but no actual actions taken Drastic changes required, effort needed is higher than what anyone can commit to Problem more complex than it appeared, implementation eventually abandoned Implementation essentially done, but not deployed all the way through and left unfinished, rotting into obsolescence To this day, one of the most successful refactoring made in Tiki was the dynamic preferences even if it required a massive effort and extended over multiple releases (hello pkdille!). The reason that lead to success were: Clear benefits to end users (consistency in UI, additional documentation, configuration search) Significant clean-up of the code making it easier for developers too Easy to understand and deploy Can be deployed gradually without causing drawbacks Not all required changes are as easy to deploy and will have as a direct benefit to the end user, but it is almost guaranteed that changes that are purely aesthetic will fail to gain traction. Simply going 'object oriented' won't cut it. Design methods using object oriented are good, but not a holy grail or a goal to aim for. Great design patterns are built and described using object oriented features, but implementing a pattern is not an objective either. Desired properties and behaviors of the code must be identified, than a design can be selected. The classes used as function libraries are not a bad thing in themselves. TikiLib is an issue because it is too large and contains completely unrelated functions, but the other ones provide a good overview to what is available for a given feature. Something that is often crucially missing in well design object oriented libraries. The concept is entrenched in Tiki and thinking it will go away is wishful thinking. The problems lie within those libraries, not in their existence. Tiki should provide better utilities for developers than it does now, but going for a share parent class will only bring back to the same issues we have right now with TikiLib. There are a few common patterns in Tiki that lead to code smell. Targeting those patterns would lead to better code. It may be subtle, but work has begun a long time ago. Listing functions in the libraries have a growing number of arguments. The ordering is only based on the evolution of the function itself. Multiple filters and formatting options appear and cause the hand-built SQL to be low-performing, hard to debug and generally unstable CRUD functionality is essentially composed of a hand-built SQL query. Depending on some preferences, the data may be altered or the operation may be prevented at all. After the actual update of the data, various other operations are performed, like updating indexes, user scores, backlinks, contributions and a whole series of other manipulations. Somewhere in the process, notifications are sent out. The PHP files in the Tiki root simply perform too much work and have no consistency on how tasks are performed. The Unified Search project aims at the listing issue by providing a flexible search index interface allowing for customizable output formatting and advanced filtering. The need for these parameters will be scaled down as we move forward. Perhaps we can begin to remove them. The SQL query building part could easily be solved using database utility methods. It would reduce the amount of errors made and simplify the code. It can easily be deployed over time The pre and post behavior could be triggered through the SignalSlot pattern, allowing external code to hook into the save process without affecting the actual library. A data container could be sent around for the pre hooks to allow them to alter the data or interrupt the chain altogether. The cross-feature behaviors could be registered only once and apply where needed. A drawback of this approach is that the code becomes harder to trace. As there are more dynamic bindings, knowing which pieces of code run becomes more of an issue. To mitigate this, the data container could contain a debug log for the different pieces of code to indicate that they ran and summarize what they did, allowing developers to look into what happened. Forms are always defined in template file. The PHP file then collects the input in a ad-hoc manner, converts the format into what is expected by the library (which is close to the database in most cases). The library then pushes the data to the database. Better facilities are required to collect the data from the request and in many case, the format taken by the library has to be standardized. Just like list functions, the order of the arguments is arbitrary in most cases. Tiki should provide functionality to support form validation, both on the PHP side and on the browser side. This could be done in a number of ways, but could be composed of form field configurations and smarty plugins to include within the forms. The additions should remain a toolkit rather than an obligation to allow for gradual deployment and preserve the flexibility. Preserving the environment is always an issue. Compatibility has to be maintained, expectations must be met. Developers have been used to flexibility in Tiki and any framework that constrains what can be done (remember Magic?) is likely not to gain support. The codebase is large and not everything can be done within a single release cycle. [Less]

It is often criticized that the source code in Tiki is not object-oriented enough. There are several issues this brings up when adapting the code to new needs. Most of which are code duplication, inconsistency in behavior and growing functions with ... [More] loosely coupled concepts. There have been multiple proposals in the past which resulted in little to no results. The following factors may be the cause: Lack of involvement, multiple +1 but no actual actions taken Drastic changes required, effort needed is higher than what anyone can commit to Problem more complex than it appeared, implementation eventually abandoned Implementation essentially done, but not deployed all the way through and left unfinished, rotting into obsolescence To this day, one of the most successful refactoring made in Tiki was the dynamic preferences even if it required a massive effort and extended over multiple releases (hello pkdille!). The reason that lead to success were: Clear benefits to end users (consistency in UI, additional documentation, configuration search) Significant clean-up of the code making it easier for developers too Easy to understand and deploy Can be deployed gradually without causing drawbacks Not all required changes are as easy to deploy and will have as a direct benefit to the end user, but it is almost guaranteed that changes that are purely aesthetic will fail to gain traction. Simply going 'object oriented' won't cut it. Design methods using object oriented are good, but not a holy grail or a goal to aim for. Great design patterns are built and described using object oriented features, but implementing a pattern is not an objective either. Desired properties and behaviors of the code must be identified, than a design can be selected. The classes used as function libraries are not a bad thing in themselves. TikiLib is an issue because it is too large and contains completely unrelated functions, but the other ones provide a good overview to what is available for a given feature. Something that is often crucially missing in well design object oriented libraries. The concept is entrenched in Tiki and thinking it will go away is wishful thinking. The problems lie within those libraries, not in their existence. Tiki should provide better utilities for developers than it does now, but going for a share parent class will only bring back to the same issues we have right now with TikiLib. There are a few common patterns in Tiki that lead to code smell. Targeting those patterns would lead to better code. It may be subtle, but work has begun a long time ago. Listing functions in the libraries have a growing number of arguments. The ordering is only based on the evolution of the function itself. Multiple filters and formatting options appear and cause the hand-built SQL to be low-performing, hard to debug and generally unstable CRUD functionality is essentially composed of a hand-built SQL query. Depending on some preferences, the data may be altered or the operation may be prevented at all. After the actual update of the data, various other operations are performed, like updating indexes, user scores, backlinks, contributions and a whole series of other manipulations. Somewhere in the process, notifications are sent out. The PHP files in the Tiki root simply perform too much work and have no consistency on how tasks are performed. The Unified Search project aims at the listing issue by providing a flexible search index interface allowing for customizable output formatting and advanced filtering. The need for these parameters will be scaled down as we move forward. Perhaps we can begin to remove them. The SQL query building part could easily be solved using database utility methods. It would reduce the amount of errors made and simplify the code. It can easily be deployed over time The pre and post behavior could be triggered through the SignalSlot pattern, allowing external code to hook into the save process without affecting the actual library. A data container could be sent around for the pre hooks to allow them to alter the data or interrupt the chain altogether. The cross-feature behaviors could be registered only once and apply where needed. A drawback of this approach is that the code becomes harder to trace. As there are more dynamic bindings, knowing which pieces of code run becomes more of an issue. To mitigate this, the data container could contain a debug log for the different pieces of code to indicate that they ran and summarize what they did, allowing developers to look into what happened. Forms are always defined in template file. The PHP file then collects the input in a ad-hoc manner, converts the format into what is expected by the library (which is close to the database in most cases). The library then pushes the data to the database. Better facilities are required to collect the data from the request and in many case, the format taken by the library has to be standardized. Just like list functions, the order of the arguments is arbitrary in most cases. Tiki should provide functionality to support form validation, both on the PHP side and on the browser side. This could be done in a number of ways, but could be composed of form field configurations and smarty plugins to include within the forms. The additions should remain a toolkit rather than an obligation to allow for gradual deployment and preserve the flexibility. Preserving the environment is always an issue. Compatibility has to be maintained, expectations must be met. Developers have been used to flexibility in Tiki and any framework that constrains what can be done (remember Magic?) is likely not to gain support. The codebase is large and not everything can be done within a single release cycle. [Less]