orchidhq / orchid Goto Github PK
View Code? Open in Web Editor NEWBuild and deploy beautiful documentation sites that grow with you
Home Page: https://orchid.run
License: GNU General Public License v3.0
Build and deploy beautiful documentation sites that grow with you
Home Page: https://orchid.run
License: GNU General Public License v3.0
Add an Options Extractor that references an item/items in another Collection. These must be lazily-loaded, just like Menus and Components, as not all generators have finished indexing by the time they are referenced, and should allow one to refer to an item in a Collection by a String ID. Requires some pretty significant refactoring of how Pages and Collections are built/indexed:
The templates for the Javadoc plugin need to be fully implemented.
Outstanding tasks
Classdoc
Packagedoc
interface
, class
, enum
, exception
, error
, and annotation
.Other
Assets are typically binary or non-content files that ar not useful to include in the index. They should be included in a Collection, but not the index. This will also keep assets out of sitemaps and meta/index files, which is also desired.
Add Gradle plugin to run Orchid from Kotlin's "Javadoc" Dokka. May need to reach out to the Dokka team to find the simplest way to integrate Dokka and Orchid, hopefully without re-inventing their build tool.
Tags
figure
Filters
Move Index generation and site search to a new plugin. This includes the current IndexGenerator, which creates the generator-specific sub-indices as well as the root index, but also the creation of a new generator that creates a .json
file to accompany each indexed page that can be loaded more selectively.
This also allows us to move the Javascript for Lunr.js and OrchidSearch out of core, and should be added to pages as an asset-only component. Themes will still be expected to implement their own search interface that works well within their own theme, but there can be an additional, generic searchbar component that can be used in themes that don' natively support search.
Form component should optionally inject a Javascript snippet to submit the form via AJAX rather than the normal HTTP form submission On submission, the form is replaced by either a generic message (if the Form doesn't have a submission page), or else the content of the Submission page.
Also see about handling return data from a server of a specific format, to be included on the generated submission pages. It should use Javascript to show the data submitted, and also show errors if it was wrong, along with a link back to the original form.
Add a concept of "Post Series" to the Posts plugins This should:
Encapsulate Component styling. Add Flag to enable/disable shadow DOM. When shadow DOM is disabled, wrap all component styling in a selector created for that individual component, and render those assets as SCSS. Alternatively, use Polymer/polyfills to support Shadow DOM in older browsers as well
Catch all exceptions thrown from generator startIndexing
and startGenerating
callbacks. Also add an event that can be fired anywhere notifying of an error. These errors should be collected and then displayed in bulk after the build process, after displaying the build statistics, so users can clearly see what needs to be fixed.
This plugin should search the entire Index and group pages into custom taxonomies, in a manner similar to Hugo. Content should not be restricted to any single generator, and is read generically from Front Matter, so can work with any Page type, and also takes Archetypes into account, making it easy to apply taxonomies to a wide range of pages without needing to maintain it on each.
This would effectively replace blog Tags (but perhaps still keep Categories, as they will eventually be hierarchical and are managed by directory), and would eliminate the need for Post Series as a special thing in the Posts plugin. I may want to remove generated Post archives, in lieu of Taxonomy pages that target the Categories.
Internally, Taxonomies are a late-running Generator, which reads all currently-indexed pages for taxonomies, building paginated archives for them all, as well as landing pages for the taxonomies showing the different taxonomy type and the terms under it. Taxonomies can each define permalinks for generated pages, and also decide whether a page can have multiple terms for a single taxonomy. Taxonomies also generate Collections of related pages.
Plugin Features
Taxonomy Configuration Options
By default, Authors are just the short description in the generator options. Author Pages should come from a file in posts/authors
(configurable) with arbitrary content, and Authors with a page can provide a link to this page. Only Authors that are specified in the Generator options or in the Author pages will have Pages generated; Authors defined on the post are said to be "guest authors".
Create a new plugin that adds Netlify CMS to an Orchid site. It should:
admin/index.html
and admin/config.yml
files:
Add a component that handles return data from a server of a specific format, to be included on the generated submission pages. It should use Javascript to show the data submitted, and also show errors if it was wrong, along with a link back to the original form.
Allow categories to be described as a tree, instead of a flat list. Category archives then include all pages from the posts in its own category and all its child categories, recursively. This should go to the very root of the blog, which includes every blog post in every category.
Allow Javadoc plugin to be run when there is no source. At least for the time being, this will allow Orchid to still be run on all the kotlin subprojects, since there are still "sources", but they are all in resources and not in Java source files
Within IndexGenerator, for every page, generate an accompanying .json file containing that page's content, so that Orchid sites could potentially have their content loaded quickly within mobile apps without necessarily needing a full webview and all related assets.
This would allow us to download a single file via AJAX and show all available versions of the project from all archived versions of the docs.
Feed Options
Gradle plugins (in buildSrc
) should include:
Each plugin should be distributed as its own plugin on the Gradle Plugins Portal. All "additional" plugins should either require the core plugin or have the core plugin bundled with it.
Also, add Gradle plugin to run Orchid from Kotlin's "Javadoc" Dokka. May need to reach out to the Dokka team to find the simplest way to integrate Dokka and Orchid, hopefully without re-inventing their build tool.
Subtasks
Allow components to declare how many components of that type are allowable on a page. Practically speaking, this would be limited to how many are declared in a single ComponentHolder
Currently, drafts are set only by the boolean property on OrchidPage. This would allow drafts to be changed dynamically based on date. In a site that is continuously generated, it would allow pages to be written with a future publish date in mind, knowing that on that date the Page will automatically no longer be a draft. Likewise, we can set up pages with a limited lifespan, knowing they will be hidden after a specific date.
It is currently hard-coded to add site
, theme
, config
, and index
into every page. Instead, we should pull these objects from a Guice-injected set of "global object factories", which also allows other plugins to add their own global variables.
Currently, Components are only rendered sequentially on the page, and they can only be set up in the page's configs. This is great, and should be the preferred method of rendering components. However, we should be able to declare and render Components within the actual page template or in the pre-compiler step of the page content as well, in a manner similar to OctoberCMS components.
There are two situations when rendering components like this:
Make dedicated AssetPage, CssPage, and JsPage classes to provide additional functionality to adding CSS and JS, such as wrapping CSS in an extra selector or combining multiple resources into one bundle. JS assets should be able to set whether they are a head or body script, and also set things like "async"
Currently, we only support finding resources one-at-a-time or by directory. Directory search can be recursive and can filter by file extension, but we should also allow lookups by a glob pattern. This would be useful in situations such as nested post categories, allowing each category to exclude the subtrees for its inner categories.
This could be implemented as another callback in the ResourceSource class. By default, it would find out the topmost directory to search, then match each file in that individually to the glob pattern. For the File resource source, we can use the Java nio
glob search functionality for performance optimization. Alternatively, we could just skip over resource sources that do not support glob searches, leaving just file searches for globs.
Currently, datafiles simply overwrite the corresponding keys in the parent-level map. Instead, deep-merge datafiles options into the full site config, appending arrays and combining map keys, rather than overwriting.
The themes tend to lag behind the plugin development progress, and they need to be brought back up-to-speed.
All Themes
Setup the Sitemap as an index sitemap, where each sub-sitemap is the sitemap from each Generator. https://www.sitemaps.org/protocol.html
Include the sitemap in the robots.txt file.
Currently all post categories use the same configs which are set on the generator. Configs should be moved to the category model and used from there, in the same way that taxonomies are configured, so that each category can have its own permalink, pagination, template, etc.
Need to research support for various popular frameworks. Might include an option to choose your framework, and the "spoofing" mechanism is tailored to that application. Would likely be very hard-coded.
We than then ensure certain methods are only called when they data they need is set up. For example, never allow ComponentHolders or Menus to set up their inner members before indexing is complete. This would be controlled via AOP and Guice annotations for simplicity, and so that we don't have anything that is tightly enforcing these rules.
Remove the archive pages functionality from the Posts plugin, and instead rely wholly on the the Taxonomies plugin to implement the archive pages feature. This will help keep these plugins focused while also encouraging users to use multiple plugins, and only those that they really want.
Set a timeout on the file watcher updates so that a build only happens once per edit. The build process itself should not allow another build to be queued while one is currently running, instead it should just drop the job.
Posts should be able to be set as a collaboration between several Authors. Any number of Authors may be added to a Post, but only a single one can be the Primary Author. If there is only one Author for a post, they are automatically the Primary Author.
The documentation must be complete before Orchid is ready for public release. Specifically:
Have Orchid install a SecurityManager implementation that enforces reads and writes to the filesystem. Ensure that we only read from a certain directory and deeper (which should default to the project root directory, set in the gradle task), and only write to or delete from the output directory or system temporary directories.
Along with this, create a Presentation layout that displays the presentation full-screen and is not based on the current theme. Of course, the Theme may provide their own Presentation layout if they desire.
In a similar manner to how we add a Gradle check to OrchidCore for release notes, add a check to each plugin, bundle, and theme project to ensure they all have pages represented in the OrchidCore Orchid site. Possible allow others to list unofficial plugins in the same pages, but we must always have the official plugins and themes with their own pages.
May want to include this in the Page base class
Set up Providers for certain core, injectable classes. Then instead of binding the class to the implementation, we inject the set and force possible choices and pick the one with the highest priority, or pick one based on a Flag. This way, other plugins would have a way to replace core functionality, and users would also be able to make these choices for themselves if they desire. An example would be replacing the FileRenderer with one that uploads directly to a CDN
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.